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Abstract 

The  United  States  Air  Force’s  Navstar  Global  Positioning  System  (GPS)  provides  high- 
accuracy  space-based  navigation  and  time  distribution  to  suitably-equipped  military  and  civilian 
users.  The  system  consists  of  earth-orbiting  satellites  and  a  world- wide  network  of  ground  stations. 
A  single  operational  control  center,  the  GPS  Master  Control  Station  (MCS)  monitors,  maintains, 
and  conunsuids  the  GPS  satellite  constellation.  The  on-going  deployment  of  the  complete  satellite 
constellation  and  recent  changes  in  the  operational  crew  structure  may  invalidate  previously  used 
planning  sind  msmagement  paradigms.  There  is  currently  no  analytical  method  for  predicting  the 
impact  of  these  and  other  environmental  changes  on  system  parameters  and  performance.  Exten¬ 
sive  testing  cannot  be  performed  .at  the  MCS  itself  due  to  the  criticality  of  the  GPS  mission  and  lack 
of  operational  redundancy.  This  research  provides  and  validates  a  discret  event  simulation  model 
of  the  MCS  operations  center  taak  flow,  focusing  on  the  creation  and  testing  of  a  sliding-widow 
MCS  activity  scheduler.  The  simulation  was  validated  using  MCS  historical  data.  Experiments 
were  conducted  by  varying  the  number  of  ground  stations  and  satellite  constellation  size  available 
to  the  simulation.  The  results,  while  not  quantitatively  trustworthy,  were  used  to  draw  general 
conclusions  about  the  GPS  operational  environment. 
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A  Model  of  Global  Positioning  System  (GPS) 
Master  Control  Station  (MCS)  Operations 


/.  Introduction. 


1.1  Problem. 

The  United  States  Air  Force’s  Navstar  Global  Positioning  System  (GPS)  is  rapidly  approach¬ 
ing  fully  operational  status.  The  mission  of  the  GPS  is  to  provide  high-accuracy  space-based 
navigation  and  time  distribution  to  suitably  ?quipped  military  and  civilian  users  (5:1).  The  system 
consists  of  a  growing  number  of  earth-orbiting  satellites,  a  world-wide  network  of  ground  stations 
and  communications  segments,  and  a  single  operational  control  center,  the  GPS  Master  Control 
Station  (MCS).  The  MCS,  its  ground  stations  and  support  facilities,  and  the  communications 
network  needed  to  interconnect  these  facilities,  constitute  the  GPS  Operational  Control  System 
(OCS). 

The  MCS  monitors,  maintains,  and  commands  the  GPS  satellite  constellation.  It  operates 
continuously  with  a  crew  of  eight  active-duty  Air  Force  personnel.  Their  primary  responsibilities 
are  maintaining  GPS  time  and  navigation  accuracy  and  periodically  assessing  the  functional  health 
of  each  GPS  space  vehicle  (SV)  (5:11).  Continuous  monitoring  of  satellite  navigation  data  transmis¬ 
sions,  forwarded  to  the  MCS  from  five  remote  Monitor  Stations  (MS),  allow  the  system  positioning 
and  timing  etccuracy  to  be  evaluated.  Four  GPS  Ground  Antennae  (GAs)  provide  the  primary 
means  of  directly  contacting  SVs  to  upload  improved  navigation  data,  collect  SV  telemetry,  and 
command  configuration  changes. 

The  on-going  deployment  of  the  complete  satellite  constellation  and  other  changes  in  the 
operational  crew  structure  may  invalidate  previously  used  planning  and  management  paradigms. 


1-1 


There  U  currently  no  analytical  method  for  predicting  the  impact  of  these  and  other  environmental 
changes  on  system  parameters  and  performance.  Extensive  testing  cannot  be  performed  at  the  MCS 
itself  due  to  the  criticality  of  the  GPS  mission  and  lack  of  operational  redundancy.  One  solution 
to  this  problem  is  to  create  a  simulation  model  of  the  MCS  operational  activity  and  perform  the 
needed  testing  and  experimentation  using  this  tool.  This  will  allow  both  planned  and  unplanned 
events  affecting  the  MCS  to  be  assessed  without  impact  to  current  operations.  This  thesis  provides 
and  validates  such  a  model  and  uses  it  to  perform  experiments  on  the  probable  operational  impact 
of  changes  to  the  GPS  operational  environment. 


1.2  Proposed  Solution. 

A  model  will  be  created,  validated,  and  used  to  perform  experiments  in  order  to  predict 
the  performance  of  the  Global  Positioning  System  Operational  Control  System  under  a  number  of 
operational  environment  conditions.  The  model  could  allow  GPS  management  to  predict  system 
resource  loading  under  circumstances  not  yet  experienced  by  the  system.  It  could  also  allow  “what- 
ir  analysis  to  be  performed  to  determine  the  response  of  mission  effectiveness  criteria  to  predicted 
system  configuration  changes. 


J.S  Methodology. 

In  detail,  this  thesis  will: 


•  Describe  and  evaluate  current  literature  on  the  Global  Positioning  System  organizational 
structure  and  operations,  system  modeling,  simulation,  and  scheduling, 

•  Determine  measurable  criteria  for  evaluating  the  performance  of  the  GPS  MCS.  MCS  output 
products  such  as  system  computer  and  crew  logs,  operational  performance  measures,  and 
interviews  with  GPS  operations  staff  and  crews  will  be  used  to  develop  these  criteria, 

•  Evaluate  competing  methodologies  for  producing  a  model  of  the  operations  task  (low  at  the 
MCS,  based  on  the  data  gathered  and  (he  established  performance  criteria, 

•  Develop  a  model  of  current  GPS  MCS  operations,  including  (as  a  minimum)  the  effects  of; 

-  Satellite  contact  requirements, 

i 
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-  Satellite  constellation  size, 

-  Ground  station  availability, 

-  MCS  crew  availability  and  operational  constraints,  and 

-  Unscheduled  OCS  resource  outages. 

•  Validate  the  MCS  model  against  current  operational  data  not  used  in  the  development  of  the 
model, 

•  Create  performance  baselines  for  both  the  current  system  configuration  and  the  planned  24 
satellite  operational  '-castellation, 

•  Perform  the  experiments  using  the  model  and  evaluate  the  results  against  the  current  perfor¬ 
mance  baselines. 


1.4  Implementaiton 


It  was  determined  that  a  computer  simulation  was  the  best  model  type  for  this  task.  Factors 
leading  to  this  decision  were  the  iterative  nature  of  the  scheduling  technique  to  be  used  and  the 
need  to  emulate  the  stochastic  MCS  activity  durations.  SIMSCRIPT  11.5  (a  registered  trademark 
of  CACI  Products  Company)  was  the  simulation  language  selected  to  implement  the  model.  The 
organization  of  the  model  program  was  tailored  to  correspond  to  the  functional  organization  of  the 
MCS,  to  aid  in  development  and  performance  verification.  To  validate  the  completed  simulation, 
a  program  environment  was  created  to  duplicate  the  conditions  that  existed  at  the  MCS  on  OOOOZ 
on  10  April  1992.  The  simulation  was  then  executed  and  its  scheduling  performance  was  compared 
the  actual  MCS  Master  Contact  Schedule  for  that  day  The  result  wm  that  35.09%  (20  of  57) 
of  the  satellite  activities  scheduled  by  the  simulation  were  within  ten  minutes  of  the  histo-ical 
scheduled  time,  and  31.58%  (18  of  57)  exceeded  one  hour.  On  this  basis,  the  model  was  judged  to 
be  insufficiently  accurate  to  allow  direct  quantitative  comparison  to  MCS  performance.  However, 
experimentation  was  performed  to  allow  a  qualitative  analysis  of  the  models  performance  under 
various  conditions. 
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1.5  ResulU, 


The  results  of  experimentation  indicate  the  model  may  be  useful  for  predicting  the  genera! 
behavior  of  the  Global  Positioning  System  Master  Control  Station  operational  performance.  The 
relationships  between  MCS  resource  scheduling  capability  and  mission  requirements  were  charac¬ 
terised,  as  were  the  effects  of  satellite  constellation  growth  and  ground  station  outage.  While  the 
results  are  not  useful  in  predicting  actual  resource  utilization  rates,  they  do  indicate  what  can  be 
expected  in  terms  of  relative  utilization  and  rate  of  increased  resource  use. 


II.  Background 


2.1  Chapter  Overview. 

The  creation  of  a  simulation  requires  a  comprehensive  understanding  of  two  systems.  The 
first  is  the  system  being  modeled.  These  objects  include  the  people  operating  the  system  (if  any), 
the  devices  used  (again,  if  any),  and  the  resources  the  system  consumes  or  produces.  The  system 
being  modeled  here  is  the  Global  Positioning  System,  which  requires  all  the  above  objects  This 
chapter  will  describe  this  system  in  detail,  using  information  from  GPS  program  development 
documentation,  actual  system  operating  instructions,  and  first-hand  GPS  operational  experience. 

The  second  ^system  requiring  in-depth  familiarity  is  the  modeling  environment  itself.  Creation 
of  an  effective  model  requires  knowledge  of  general  simulation  and  operations  research  theory;  the 
relative  advantages  of  alternative  modeling  systems;  and  in-depth  knowledge  of  the  environment 
selected  for  use.  These  topics  as  they  pertain  to  this  research  are  covered  in  this  chapter. 

t.B  The  Navaiar  Global  Poaiiioning  Syaiem. 

The  Navstar  Global  Positioning  System  (GPS)  is  the  United  States  Air  Force’s  space-based, 
highly-accurate  radionavigation  system.  Since  it  was  first  made  available  for  three-dimensional 
position  determination  in  December  1978,  this  system  has  created  a  revolution  in  disciplines  such 
as  navigation,  ordinance  delivery,  search  and  rescue,  surveying,  and  precise  timing  (10:1-7).  The 
GPS  allows  any  number  of  properly-equipped  users  to  simultaneously  determine  their  time  to  within 
100  nanoseconds  of  Universal  Time;  their  position  within  16  meters  spherical  error  probable  (SEP) 
(5:8),  and  their  velocity  to  within  0.2  meters  per  second  (10:1-13). 

Very  simply,  GPS  consists  of  a  number  of  earth- orbiting  satellites  that  continuously  broadcast 
the  current  t.'me  and  their  orbital  parameters.  Users  equipped  with  GPS  receiver  sets  on  land,  .sea, 
in  the  air,  and  in  low-earth  orbit,  receive  this  information  from  all  the  satellites  in  their  view.  Sign 
and  data  processing  components  in  the  receiver  set  estimate  the  current  position  of  each  satellite 
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and  measure  the  propagation  delay  of  radio  signsds  from  the  satellite  to  the  user.  Using  these  time 
delays,  the  set  solves  simultaneous  equations  (one  for  each  satellite  used)  in  position  and  time  to 
produce  the  ustrs  time,  position,  and  velocity. 

The  accuracy  of  the  above  calculations  depends  on  knowing  the  satellite  time  and  position 
precisely.  However,  the  satellite  on*board  time  standard  and  the  satellite  orbits  are  subject  to  both 
random  and  cumulative  error.  GPS  satellites  are  currently  not  able  to  make  autonomous  and  real¬ 
time  corrections  to  the  time  and  position  data  they  broadcast,  so  a  network  of  monitoring  receivers 
continuously  collect  satellite  range  data.  These  data  are  transmitted  to  a  master  control  station, 
where  accurate  estimates  of  satellite  time  standard  drift  and  orbital  trajectory  are  calculated. 
These  estimates  are  mathematically  propagat-d  into  future,  formed  into  the  proper  data  format, 
and  transmitted  back  to  the  satellites  via  transmitting  antennas.  The  satellite  then  retransmits 
this  data  to  the  users. 

As  a  system,  the  GPS  consists  of  three  major  subsystems  (Figure  2.1).  The  Space  segment 
consists  of  the  satellite  constellation.  The  Control  Segment  is  the  Master  Control  Station,  the 
monitoring  and  transmitting  stations,  and  the  communications  links  between  them.  Finally,  the 
User  Segment  is  the  community  of  military  and  civilian  organizations  and  personnel  equipped  with 
GPS  receiver  sets.  The  functional  inter-relationship  of  these  segments  is  diagrammed  in  Figure  2.2. 
Each  segment  is  described  in  detail  in  the  following  sections. 

S.S.l  Space  Segment.  The  Space  Segment  is  a  growing  number  of  earth-orbiting  satellite 
vehicles  (SVs),  which  constitute  the  GPS  “constellation”.  An  understanding  of  function  of  the 
satellites  and  the  implications  of  the  geometry  of  their  orbits  is  required  for  correct  model  design 
and  analysis. 

2.S.I.1  GPS  Satellite  Orbits.  The  orbital  height  for  operational  GPS  SVs  is  nominally 
10,930  nautical  miles,  or  about  20,200  kilometers.  This  orbital  altitude  gives  the  satellites  an  1 1  hour 
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58  minute  (semi-synchronous)  orbital  period.  Wben  combined  with  the  motion  of  the  Earth,  this 
orbit  results  in  each  satellite  appearing  in  the  same  location  of  the  sky  once  pet  day  for  a  fixed 
observer.  However,  the  difference  between  the  satellite  orbital  period  and  the  length  of  the  solar 
day  causes  each  satellite  to  appear  approximately  4  minutes  earlier  each  day.  The  intended  orbits 
are  circular;  in  practice,  most  have  an  eccentricity  of  less  than  0.01.  There  are  six  orbital  planes, 
labeled  “A”  through  “F”,  into  which  the  satellites  are  launched.  There  will  be  four  satellite  in  each 
plane,  spaced  90  degrees  apaut.  As  noted  below,  the  orbital  planes  of  the  research  and  development 
SVs  have  a  greater  inclination  than  that  of  the  operational  satellites. 

The  orbital  parameters  of  the  GPS  constellation  V'ere  chosen  to  optimize  the  performance 
of  the  navigation  missicn.  There  are  a  number  of  tradeoffs  involved.  High  altitude  orbits  provide 
long  periods  of  visibility  for  a  given  location  on  the  Earth,  but  these  distances  require  greater 
transmitted  signal  power  for  reliable  communication.  At  lower  altitudes,  however,  the  SV/user 
range  changes  rapidly  as  the  satellite  peuses  overhead,  degrading  system  accuracy. 

2. 2. 1.2  GPS  Satellitea.  From  February  1978  to  September  1985,  ten  GPS  research  and 
development  satellites  (collectively  called  "Block  1”)  were  launched.  These  satellites,  designed  and 
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built  by  Rockwell  International,  were  designated  BI  (for  Block  1)  -1  through  -11.  (The  numbering 
discrepancy  arises  from  the  launch  failure  of  BI-5,  whose  Atlas  booster  exploded  on  the  launch  pad 
in  December  1981  (10:1-8).)  These  spacecraft,  intended  to  have  a  five-year  lifespan,  allowed  the 
GPS  concept  to  be  tested  and  validated.  The  Block  I  satellites  have  shown  remarkable  longevity, 
however,  and  four  of  these  SVs  were  still  providing  service  as  of  July  1992  (3).  The  eldest  of  these, 
BI-8,  was  launched  in  July  1983  (10:1-8).  Block  I  GPS  satellites  have  an  orbital  inclination  of  64 
degrees,  as  opposed  to  55  degrees  for  the  operational  constellation.  This  was  to  improve  satellite 
visibility  over  the  test  sites  (primarily  the  Yuma  Proving  Ground  in  Arizona)  during  the  system 
test  and  evaluation  phase  (10:1-6). 

The  launching  of  operational  satellites  began  in  February  1989  and  continues  to  the  present. 
These  satellites,  labeled  Block  II,  in  addition  to  being  larger  and  more  expensive,  have  additional 
capabilities  over  the  Block  I  SVs.  While  the  Block  I  on-board  satellite  navigation  processors  had 
only  enough  memory  to  retain  26  hours  of  navigational  data,  the  Block  II  SVs  can  store  14  days 
of  usable  data.  The  Block  II  vehicle  electronics  suite  was  hardened  against  radiation,  the  effects 
of  which  plagued  the  Block  I  vehicles.  The  design  life  of  Block  II  GPS  SVs  is  7.5  years  (5:91). 
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A  subsequent  upgrade  to  the  Block  II  vehicles,  designated  Block  11  A,  further  increased  the  usable 
on-board  navigation  data  storage  to  180  days.  The  Block  II  SVs  are  numbers  BIl-1  to  BlI-9; 
BlI-10  was  the  first  Block  IIA  satellite.  The  Block  II  satellites  can  be  programmed  to  prevent 
users  without  official  authorization  (in  the  form  of  cryptographic  keys)  from  using  the  system  to 
its  fullest  capability. 

The  current  target  is  to  have  a  constellation  of  21  operational  satellites  with  three  on-orbit 
spares  (5:7).  The  spares  will  be  active,  bringing  the  minimal  number  of  usable  satellites  for  an 
operational  system  up  to  24  (10:1-3).  This  number  does  not  include  the  remaining  operational 
Block  I  satellites.  The  upper  limit  to  the  number  of  operational  satellites  is  30,  due  to  the  design  of 
the  Master  Control  Station  (MCS)  (5:11).  A  24  satellite  constellation  will  result  in  the  98%  three- 
dimensional  positioning  availability  requirement  specified  in  the  System  Operational  Requirements 
Document  (SORD)  (10:6-2). 

As  a  secondary  payload,  the  later  Block  1  and  all  subsequent  satellites  carry  nuclear  burst 
detection  sensors,  part  of  the  Nuclear  Detonation  (NUDET)  Detection  System  (NDS).  These  sensors 
detect  the  detonation  of  nuclear  devices  anywhere  in  the  world  and  relay  the  exact  time  and  range 
of  the  burst  to  suitably  equipped  receivers.  This  data,  hopefully  from  multiple  satellites,  is  then 
used  to  calculate  the  precise  time  and  location  of  the  detonation. 

2.S.2  User  Segment.  Military  and  civilian  users  who  require  precise  time  or  position  infor¬ 
mation  and  are  equipped  with  suitable  GPS  receivers  make  up  the  User  Segment.  As  described 
above,  ewh  satellite  continuously  broadcasts  information  that  allows  GPS  receivers  to  calculate 
the  satellite’s  position  with  respect  to  a  common  reference  system.  With  information  from  three 
satellites,  the  GPS  receiver  can  compute  (“triangulate”,  in  a  sense)  the  users’  position  and  velocity- 
in  three  dimensions.  However,  because  the  receiver  set’s  clock  must  be  synchronized  with  the  GPS 
common  time,  the  information  from  a  fourth  satellite  is  needed  to  derive  the  users’  local  clock/GPS 
time  offset.  If  the  user  knows  (or  does  not  care  to  know)  any  part  of  the  time  and  position  equation, 
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the  remaining  unknowns  can  be  calculated  with  data  from  fewer  than  four  satellites.  Two  exam¬ 
ples  of  this  are  ships  at  sea  (their  height  above  sea  level  is  known)  and  users  with  highly  accurate 
time  standards  synchronized  to  GPS  time.  These  users  would  require  information  from  only  three 
satellites. 

A  importauit  byproduct  of  this  process  is  that  the  user  now  has  an  extremely  accurate  time 
reference,  as  part  of  the  of  data  received  from  the  satellite  describes  the  offset  between  GPS  time 
and  Universal  Coordinated  Time,  or  UTC.  These  data  allow  suitably  equipped  users  to  calculate 
the  local  time  to  within  100  nanoseconds  (100  billionths  of  a  second)  of  UTC 

There  are  two  levels  of  GPS  accuracy:  the  Precise  Positioning  Service  (PPS)  and  the  Standard 
Positioning  Service  (SPS).  PPS  users  ate  those  with  both  a  suitably-equipped  user  set  and  the 
necessary  cryptological  keys  to  decode  the  PPS  transmissions  from  the  GPS  satellites.  Users  with 
PPS-incompatible  receivers,  and  authorized  users  without  cryptokeys,  are  restricted  to  the  SPS. 
PPS  provides  positional  accuracy  with  errors  no  greater  than  16  meters  Spherical  Error  Probable 
(three  dimensional  error  not  to  exceed  16  meters),  while  SPS  provides  76  meters  SEP.  Both  types 
of  users  have  access  to  precise  time  and  time  interval  information  (5:7). 

Receiver  sets  vary  in  size  and  sophistication  dependent  on  the  requirements  of  the  users.  For 
instance,  the  Smsdl,  Lightweight  GPS  Receiver  (SLGR)  hand-held  set  weighs  less  than  five  pounds 
and  will  fit  in  the  pocket  of  a  standard-issue  Battle  Dress  Uniform  (10:1-10).  This  user  set  can 
receive  only  the  SPS  signals,  which  provides  better  than  100-meter  horizontal  error  for  footsoldiers 
and  slow-moving  vehicles.  Larger  and  more  complex  receivers,  with  the  ability  to  electronically  track 
up  to  five  bVs  simultaneously,  are  designed  to  mount  in  high-performance  aircraft  and  have  the 
computing  ability  to  update  a  fast-moving  users’  position  quickly.  As  described  above,  authorized 
users  receive  cryptographic  keys  to  decode  the  highest  accuracy  signals  from  the  GPS  satellites. 

2.2.S  Control  Segment.  Lastly,  the  Control  Segment  consists  of  a  central  control  facility 
called  the  Master  Control  Station  (MCS),  a  number  of  iransmitter  and  receiver  stations  located 
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around  the  world  to  gather  system  data  and  command  and  control  the  satellite  constellation,  and 
world-wide  communications  network  that  conveys  data  to  and  commands  from  the  MCS.  The 
Control  Segment  has  the  responsibility  for  maintaining  system  availability  and  accuracy  within 
established  standards.  Using  the  dedicated  communications  network  and  ground  stations,  the  MCS 
continuously  collects  data  broadcast  by  GPS  satellites,  processes  the  data  into  accurate  satellite 
time  euid  location  predictions,  then  transmits  the  predictions  back  to  the  satellites.  This  data  in 
turn  is  rebroadcast  to  the  GPS  users,  who  use  the  data  to  solve  for  their  own  time  and  location. 
At  the  same  time  the  csdculated  data  is  transmitted  to  the  satellite,  the  operational  crew  at  the 
MCS  collects  and  reviews  satellite  telemetry  data  for  satellite  anomaly  detection  and  performance 
trending.  The  Control  Segment  is  the  focus  of  this  research  and  is  described  in  detail  in  the  following 
sections. 

£.S  GPS  Operational  Control  Segment. 

The  2nd  Satellite  Operations  Squadron  (2  SOPS),  located  at  the  Consolidated  Space  Oper¬ 
ations  Center  (CSOC),  Falcon  Air  Force  Base  (AFB),  Colorado,  has  the  mission  of  operating  the 
GPS.  Falcon  AFB  is  itself  located  approximately  15  miles  east  of  the  city  of  Colorado  Springs,  Col¬ 
orado.  The  2  SOPS,  a  subordinate  unit  of  the  50th  Space  Wing,  is  also  responsible  for  maintaining 
the  GPS  ground  stations,  maintaining  navigation  and  timing  quality  control/quality  assurance,  and 
providing  user  interface  for  special  users.  The  GPS  Control  Segment,  also  called  the  Operational 
Control  System  (OCS),  consists  of  five  Monitor  Stations  (MS),  three  standard  Ground  Anten¬ 
nas  (GA),  a  Prelaunch  Compatibility  Station  (PCS),  the  MCS,  and  the  communications  network 
needed  to  link  the  MCS  with  the  remote  stations.  The  OCS  also  may  utilize  the  ground  antenna 
(part  of  the  Air  Force  Satellite  Control  Network  (AFSCN))  located  at  Falcon  AFB.  This  GA  has 
the  AFSCN  network  designation  “PIKE”.  Each  of  these  type  of  facilities  is  described  below,  with 
Table  2.1  providing  the  exact  locations.  Figure  2.3  is  a  biock  diagram  of  the  entire  OCS. 
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Figure  2  3.  GPS  Operational  Control  Segment  (OCS)  Block  Diagram  (from  (5:119)). 


S.5.J  Monitor  Stations.  Monitor  Stations  serve  as  the  MCS’s  listening  posts  for  the  navi¬ 
gation  signals  treuismitted  by  the  satellites  overhead.  There  are  five  GPS  Monitor  Stations,  four 
scattered  about  the  globe  near  the  equator  and  one  co-located  with  the  MCS  at  Falcon  AFB.  (refer 
to  Table  2.1  for  specific  MS  location  data).  Monitor  Stations  are  sophisticated,  semi-autonomous 
receivers,  able  to  track  the  signals  of  up  to  nine  satellites  simultaneously  under  command  of  the 
MCS.  The  MCS  provides  the  MS  with  information  on  the  satellites  in  view,  allowing  data  pre¬ 
processing  at  the  MS  to  reduce  the  amount  of  data  returned  to  the  MCS  and  to  speed  the  satellite 
signal  acquisition  process. 

Monitor  Stations  process  the  signals  received  from  the  SVs  and  continuously  calculate  the 
range  between  the  MS  antenna  and  each  SV  being  tracked.  The  MS  antenna  locations  have  been 
surveyed  to  within  one  meter  to  accomplish  this  task  with  the  precision  required  (5:87).  The 
MS  transmits  the  results  of  these  measurements  to  the  MCS.  The  MCS  then  uses  these  data  to 
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Accurately  estimate  the  positions  of  the  SVs  and  the  drift  of  their  on-board  time  standards.  Another 
critical  role  of  the  MS  is  to  provide  immediate  feedback  to  the  MCS  in  the  case  of  satellite  failure 
or  anomalous  behavior.  The  MCS  crew  watches  the  availability  and  quality  of  satellite  data  from 
the  Monitor  Stations  closely  for  any  sign  of  navigation  signal  degradation  or  satellite  subsystem 
failures. 


Table  2.1.  GPS  Monitor  Station  and  Ground  Antenna  Locations  (.5:106) 


Designation 

Location 

Type 

Latitude 

(deg) 

Longitude  I 
(deg)  ! 

A3CH 

Ascension  Island. 

South  Atlantic  Ocean 

MS/GA 

7.9S 

14  4W 

COSPM 

Falcon  AFB, 

Colorado 

MS 

38.8N 

104. 5W 

PIKE 

Falcon  AFB. 

Colorado 

GA* 

38.8N 

104. 5W 

DIEG 

Diego  Garcia  Island, 
Seychelles,  Indian  Ocean 

MS/GA 

7.2S 

72. 4E 

KWAJ 

Kwajalein  Atoll, 

West  Pacific  Ocean 

MS/GA 

8.7N 

167, 7E 

HAWAIM 

Oahu,  Hawaii 

MS 

21.6N 

158.2W 

CAPE 

1 _ 

Cape  Canaveral  AFB, 
Florida** 

GA 

28. 5N 

80.6W 

*  AFSCN  Remote  Tracking  Station 
**  Prelaunch  Compatibility  Station 

S.S.2  Ground  Antennas.  The  GPS  Ground  Antennas  are  the  primary  means  for  command 
and  control  of  GPS  satellites.  The  three  dedicated  GPS  G.As  are  co-locatcd  with  Monitor  Stations 
at  Kwajalein,  Ascension,  and  Diego  Garcia,  as  described  in  Table  2.1 .  The  Prelaunch  Compatibility 
Station  (PCS)  at  Cape  Canaveral  is  an  identical  facility  used  for  ensuring  the  interoperability  of 
new  satellites  with  the  OCS  just  prior  to  launch.  When  not  reserved  foi  its  testing  role,  it  serves 
as  a  fully  functional  GA  (5:95). 

In  addition  to  these  dedicated  resources,  the  OC.S  can  use  the  .APSCN  Remote  Tracking 
Station  (RTS)  located  at  Falcon  .AFB  for  communicating  with  the  GPS  constellation.  This  is 
achieved  thiough  the  use  of  <a  unique  electronic  interface  device  that  allows  the  RTS  to  emulate 
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a  GPS  Ground  Antenna.  As  this  facility  is  not  dedicated  to  GPS  and  has  substantial  AFSCN 
commitments,  use  must  be  prearranged  with  AFSCN  schedulers.  The  AFSCN  operators  can 
perform  command  and  control  functions  on  GPS  satellites,  but  that  network  is  not  configured  to 
calculate  and  upload  navigational  data. 

Eew:h  C?S  GA  is  an  active  S-band  transmitter  and  receiver,  equipped  with  a  10-meter  diam¬ 
eter  steerable  parabolic  dish  antenna.  On  command  from  the  MCS,  the  antenna  is  pointed  using 
the  current  MCS  estimate  of  the  satellite  position.  Once  two-way  contact  is  established  with  the 
SV,  the  GA  transmits  real-time  or  prestored  commands  and  simultaneously  receives  SV  telemetry 
(5:95).  Figure  2.4  shows  schematically  what  the  relative  GA  coverage  areas  are,  given  the  GA 
longitude  and  an  approximate  140  degree  coverage  arc  (5:99). 


Figure  2.4.  GPS  Ground  Antenna  Coverage  (from  (5:99)). 


2.S.S  Commumcaiionn.  Control  Segment  communications  link  the  MS/GAe  to  the  MCS. 
There  ate  generally  two  9600  bit-per-second  (bps)  links  to  each  of  *he  GAs,  and  a  single  9600 
bps  link  to  the  MSs.  The  communications  channels  are  carried  by  both  military  and  commercial 
communications  networks  (5:100). 

2.3-4  Master  Control  Station.  The  MCS  acts  as  the  hub  for  all  GPS  activities.  Its  mission 
is  to  command  and  control  the  GPS  satellite  constellation  and  the  other  GPS  resources.  The  MCS 
is  designed  to  monitor  and  control  30  GPS  satellites  simultaneously  in  any  mix  of  Block  1  and 
Block  II  types  (5:11).  The  MCS  is  one  of  four  satellite  operations  centers  in  the  CSOC.  Physically, 
it  consists  of  the  operations  center  (“ops  center”)  itself,  the  MCS  computer  facility,  maintenance 
and  support  facilities,  the  Colorado  Springs  Monitor  Station,  and  an  NDS  mission  support  area 
operated  by  the  Air  Force  Technical  Applications  Center  (AFTAC),  the  primary  users  of  the  NDS 
data. 

In  the  ops  center,  there  are  11  computer  console  positions.  Any  of  the  six  distinct  crew 
functions  (listed  in  Table  2.2)  can  be  performed  at  any  of  the  consoles.  Detailed  descriptions  of  the 
responsibilities  of  each  crewmember  are  provided  below. 


Table  2.2.  GPS  MCS  Crew  Position  Summary 


Position 

Symbol 

O 

Rank 

Flight  Commander 

FCMDR 

1 

Lt/Maj 

Crew  Chief 

CCHIEF 

“fl 

TSgt-SMSgt 

Satellite  Analysis 
Officer 

SAO 

1 

Lt/Capt 

Satellite  Vehicle 
Officer 

SVO 

1 

Lt/Capt 

Satellite  Support 
Operator 

SSO 

3 

Amn/TSgt 

Ground  Systems 
Operator 

GSO 

1 

Amn/TSgl 

The  MCS  computer  center,  using  two  IBM  3083  mainframe  computers  and  a8.sociated  storage 
and  communications  hardware,  is  the  heart  of  the  operations  renter  The  computers,  together  with 
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the  GPS  Mission  software,  provide  all  data  processing  support  for  the  operations  mission.  The 
major  services  this  system  provides  includes: 


•  data  collection  from  the  Monitor  Stations, 

•  calculation  of  satellite  trajectory  and  satellite  and  MS  time  standard  drift  estimates, 

•  creation  and  formating  of  SV  navigation  uploads, 

•  maintenance  of  system  parameter  databases  and  logs, 

•  operations  consoles  display  format  and  control, 

•  support  for  transmission  of  GPS  data  to  external  agencies,  and 

•  support  for  internal  functions  such  as  planning,  scheduling  and  report  generation. 


The  tasks  assigned  to  each  MCS  crew  position  provide  a  comprehensive  overview  of  how  the 


MCS  performs  its  command  and  control  mission.  These  tasks  are  described  below. 


The  general 


crew  task  flow  and  interaction  is  shown  graphically  in  Figure  2.5. 
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Figure  2.5.  MCS  Crew  Organi/alion  and  Tasks  (5:37) 
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2. 3. 4- 1  Flight  Commander  (FCMDR).  The  FCMDR  monitors  and  directs  the  crew 
in  the  performance  of  mission  operations.  The  FCMDR  approves  the  schedule  for  his  shift,  makes 
schedule  changes  as  required,  and  gives  the  final  authorization  for  the  preparation  and  execution  of 
every  satellite  contact.  The  FCMDR  is  also  the  focal  point  for  communications  between  the  crew 
and  external  agencies. 

2. 3.4- 2  Crew  Chief  (CCHIEF).  The  CCHIEF,  in  addition  to  acting  as  the  deputy 
Flight  Commander,  is  responsible  for  coordinating  the  activities  of  the  MCS  with  maintenance 

V. 

functions  and  other  support  activities.  The  CCHIEF  also  performs  the  up-channel  reporting  tasks 
assigned  to  the  operational  crew. 

2. 3. 4- 3  Satellite  Support  Operator  (SSO).  The  SSO  personnel  perform  the  satellite 
contacts.  This  entails  coordinating  and  monitoring  GA  operations,  configuring  the  system  for  the 
contact,  executing  the  commands  directed  by  the  schedule,  and  recording  the  details  of  the  contact. 
The  SSO  also  reviews  satellite  telemetry  during  the  contact  and  reports  anomalies  to  the  SVO  and 
SAO. 


2. 3. 4-4  Satellite  Analysts  Officer  (SAO).  The  SAO  is  responsible  for  the  performance 
of  the  navigation  and  timing  subsystems.  This  position  monitors  mission  performance  using  data 
from  the  Monitor  Stations  and  through  satellite  telemetry  received  via  the  GAs.  The  SAO  also 
manages  the  navigation  message  generation  process,  and  assists  the  SSO  in  uploading  the  message 
to  the  SVs.  The  SAO  provides  the  primary  technical  support  for  navigation  mission  anomaly 
resolution  for  the  crew. 

2. 3.4.5  Satellite  Vehicle  Officer  (SVO).  The  SVO  functions  are  similar  to  the  SAO, 
except  that  this  position  is  lesponsible  for  all  satellite  systems  other  than  the  navigation  subsystems. 
These  include  subsystems  such  as  command/telemetry  processors,  transrnittcrs/reccivors,  altitude 
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control,  thermal  control,  and  power  generation  and  conditioning.  The  SVO  plans  the  satellite 
commanding  performed  by  the  SSO.  This  position  also  assists  in  satellite  “bus”  anomaly  resolution. 

S.S.4  S  Ground  Systems  Operator  (GSO).  The  GSO  configures  and  monitors  the  per¬ 
formance  of  the  GPS  communications  network  and  ground  stations.  The  GSO  will  also  perform 
fault  isolation  procedures  and  assist  maintenance  personnel  at  the  remote  sites  to  correct  deficien¬ 
cies  (5:37). 

S.S.5  MCS  Operations.  The  MCS  is  not  a  general  use  system;  it  is  specifically  designed  to 
perform  the  task  of  operating  the  GPS.  As  such,  there  are  a  finite  number  of  well-defined  tasks 
that  the  MCS  as  a  system  can  and  does  perform.  This  section  describes  the  MCS  task  generation 
and  scheduling  process. 

£.3.5.1  MCS  Activities.  The  GPS  program  requirement  documents  are  the  ultimate 
source  of  GPS  activities.  They  specify  the  eventual  end  product  (a  highly  accurate  radionavigation 
system)  in  detail,  defining  system  accuracy,  operational  rates,  availability  standards,  etc.  They 
describe  the  goal. 

More  detailed,  “tactical”  documents  describe  how  the  requirements  are  to  be  met,  in  teTns  of 
when  specific  activities  are  to  be  performed,  who  is  to  do  them,  and  the  criteria  for  success.  These 
documents  include  manufacturers’  technical  handbooks,  middle  echelon  requirements  documents 
such  as  the  On-Orbit  Maintenance  Requirements  (OOMR),  and  Headquarters/Wing/Squadton 
Operational  Instructions  (OI).  These  in  turn  are  broken  down  into  detailed  “how-to”  documentation 
for  the  personnel  performing  the  activities.  The  Navstar  Satellite  Support  Requirements  (NSSR)  is 
one  of  these,  produced  by  the  2  SOPS  to  d-fine  the  timing  requirements  for  each  activity  performed 
on  the  GPS  satellites 

For  the  purposes  of  this  document,  and  when  referring  to  MCS  operations,  a  requirement  is 
the  rationale  for  one  or  more  MCS  nc/ii/jfies  to  be  performed.  The  requirement  originat»«  from 
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the  GPS  system  requirements  documents  or  from  operational  squadron  operating  instructions.  An 
ictivit^  is  a  single,  discrete  function,  performed  by  the  MCS  crew  as  a  whole,  that  satisfies  a 
requirement. 

Table  2.3  shows  three  of  the  78  different  MCS  activities  described  in  the  NSSR.  ACTIVITY 
is  the  acronym  used  on  the  MCS  Master  Contact  Schedule.  SCHEDULED  describes  the  scheduling 
interval;  these  may  be  periodic  (as  shown  for  ADDKEYS),  periodic  with  caveats  (like  BAT3TEMP), 
or  aperiodic  (like  BCHGROFF). 


Table  2.3.  2  SOPS  NSSR  Excerpt  (1:7) 

SCTIVITT:  AADKtTS  (AOOUTS  truualaaion) 

SCmOUD:  Talca  par  aaak  (loiaally  on  Sondar  and  Hadnaadaj  if  LI  t 
L3  traaaalttar*  ara  anablad) . 

ICTIflTT  m:  10  mlnntoa 

PtniPOSI:  To  opload  not  aaTlfatlon  proeaaaor  addzoat  kofo. 
uquitaan:  bacata  A014T  Procadnia. 

VIlDOl:  *1  to  *t  boar  froa  tcbodnlod  tnpport  tiaa. 
ttSCnDOLO;  ieeaavllaKad  prior  to  roaalas  addraaa  kofo  to  avoid 
naaatkoriaod  accaaa  to  tba  naTl^atlon  piocataor. 

ICTITITT:  B(T3TUP  (Battorp  3  taa^aratnra  aonltor) 

SCBBOOLED:  Oaca  par  soak  than  tba  8TB  la  lOS  dagraoa  and 
daeroasia(.  (For  daolgnatod  aatallltaa  only) 
iCTITITT  TB:  10  sUatoa 

POBFOSI;  To  datarmlna  ■arlwm  battarp  3  ta^arataro. 

BBQOIBBBIT:  Parfota  Battarp  3  Taop  Honltor  Opa  Procadnra. 

VIBD9V:  */-  6  ■inntas  froa  ackadalad  Initiation  tl«a. 

USCBBDOLBD:  Rmat  aot  alolata  BIIDOV  to  ananro  that  battarp  3  doaa 
not  axcaad  60  dagraoa  Cantlgrada  nulla  connactod  to 
tba  malm  boa. 

iCTITITT:  BCBStOFF  (Battarp  ClarOoI  OFF) 

8CBEDULBD:  Aa  ro<{nirod  bp  a  acbadnlo  ra^aat 
ACTITITT  TB:  6  ■inntas 

PUIPOSB:  To  tnm  a  battarp  ebargar  off 
UqOIkBHBIT:  Parferw  Battarp  (Hiargar  Off  Opa  Pt.  .aduxo  alth  BiT.OIE, 
TWO  or  Tnn. 

VIBDOV:  *30  to  *30  Biontao  froa  acbaC.al  d  initiation  tlaa 
B<8(9K0(7LID :  Bnat  not  alolata  WIIDCra  to  av.ld  poaslblo  dasago  to  tba 

aatalllta  nnlaat  atatad  otbaraisa  bp  tba  scbodnla  roqnatt . 


The  ACTIVITY  TM  is  the  expected  duration  of  the  activity.  PURPOSE  and  REQUIRE¬ 
MENT  assists  the  scheduler  and  crew  in  verifying  the  need  for  the  activity.  The  allowed  slack 
about  the  scheduled  time  is  shown  as  WINDOW;  the  requirement  may  be  considered  failed  if  this 
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is  not  met.  Finally,  RESCHEDULED  contains  instructions  to  the  FCMDR  on  how  to  reschedule 
or  otherwise  react  in  the  case  where  the  scheduled  time  is  missed. 

t.S.S.S  MCS  Scheduling.  Taking  advantage  of  the  periodic  and  well-defined  nature 
of  satellite  support  requirements,  routine  satellite  support  activities  can  be  scheduled  in  advance. 
Scheduling  satellite  activities  is  simply  a  process  of  matching  the  time  the  activity  is  due  to  be  per¬ 
formed  with  the  resources  needed  to  perform  it.  This  process  is  complicated  by  the  shifting  SV/GA 
visibility  periods;  by  scheduled  and  unscheduled  equipment  outages;  by  conflicting  requirements; 
and  by  additional  aperiodic  contact  requirements  that  “shift"  the  time  of  routine  contacts. 

The  MCS  personnel  create  the  GPS  Master  Contact  Schedule  every  day  for  the  next  24  hour 
period  stuting  at  0600  GMT.  The  scheduling  process  is: 


1.  Find  the  visibility  of  each  SV  with  each  GA.  The  MCS  computer  system  provides  this  data  as 
a  printed  report,  using  the  current  estimates  of  SV  trajectory  to  calculate  satellite  visibility 
periods  and  elevations  at  each  of  the  ground  stations. 

2.  Collect  the  Schedule  Requests  (SR)  for  aperiodic  SV  contact  activities  and  ground  station 
maintenance.  These  requests  are  submitted  in  writing  by  staff  and  support  functions  to 
reserve  system  resources  for  maintenance  and  testing  at  some  specific  time.  The  requests  are 
channeled  to  the  scheduling  function  after  approval  by  the  FCMDR. 

3.  Identify  the  periodic  activities  that  must  be  performed  on  the  day  being  scheduled.  This  is 
done  by  examining  the  system  logs  to  find  the  last  time  these  activities  were  performed,  then 
adding  the  maximum  time  interval  (from  the  NSSR).  The  activity  must  be  performed  again 
prior  to  the  resulting  time. 

4.  Draft  the  schedule,  starting  with  the  SRo  with  fixed  activity  start  times,  then  periodic  activi¬ 
ties.  As  each  activity  is  added,  it  must  be  examined  to  ensure  it  meets  visibility  requirements, 
meets  system  requirements,  does  not  conflict  with  previously  scheduled  activities,  and  other¬ 
wise  has  the  ne-^^a  y  system  resources  available  to  accomplish  its  task. 


2.S.5.S  MCS  Operations.  During  the  performance  of  a  satellite  support,  the  MCS 
crewmembers  are  cooperating  to  perform  the  activities  on  the  Master  Contact  Schedule.  There 
may  be  zero,  one,  or  more  activities  being  performed  simultaneously  in  the  MCS  at  any  given  time, 
but  generally  a  single  crewmember  can  be  involved  in  only  one  at  a  time. 


2-16 


As  an  example,  a  common  set  of  activities  performed  during  a  satellite  contact  is  a  SV 
state-of-health  (SOH)  review,  a  download  of  SV  Global  Burst  Detector  (GBD)  processor  data  (a 
GBDDUMP),  and  finally  a  navigation  data  upload  (NAV).  The  SSO  and  the  GSO  initiate  the 
contact  by  ensuring  the  GA  is  ready.  Then  with  FCMDR  authorization,  the  SSO  commands 
the  GA  to  begin  transmitting.  After  contact  is  established  and  telemetry  from  the  SV  received, 
the  SSO  and  the  SVO  review  the  status  of  the  satellite's  subsystems  (the  SOH).  The  SSO  then 
commands  the  SV  to  download  GBD  data  (the  GBDDUMP).  While  this  was  occurring,  the  SAO 
was  commanding  the  MCS  computer  system  to  calculate  “fresh”  estimates  of  the  SV’s  clock  and 
tritjectory  parameters,  form  them  into  a  navigation  data  upload,  and  treuismit  the  upload  to  the 
GA.  The  SSO  then  instructs  the  GA  to  transmit  the  data  to  the  SV.  The  contact  ends  when  the 
SSO  and  GSO  break  the  communications  link  and  return  the  GA  to  ready  status 

The  schedule  has  been  constructed  under  the  assumption  that  each  of  the  scheduled  activities 
will  take  little  or  no  time  longer  to  perform  than  the  activity  duration  shown  in  the  NSSR.  As  the 
result  of  experience  in  both  scheduling  and  performing  these  activities,  the  durations  in  the  NSSR 
are  conservative  and  seldom  does  the  performance  time  exceed  the  expected.  Experienced  MCS 
crew  personnel  have  stated  these  durations  are  exceeded  as  result  of  satellite,  communications, 
ground  station,  or  MCS  computer  malfunction  (3),  (14). 

S.4  Modeling. 

A  model  of  a  system  is  a  representation  of  the  objects,  concepts,  or  ideas  of  the  system  in 
some  form  other  than  the  system  itself  (15:2).  System  models  of  all  types  are  simply  tools  for 
describing  system  functionality  in  a  language  understood  by  the  model  builder.  Models  are  also 
a  substitute  for  real  or  conceivable  systems  in  cases  where  the  system  itself  cannot  be  used  for 
analysis  or  is  otherwise  unavailable.  That  may  be  due  to  any  number  of  reasons.  The  system  may 
not  exist  (yet),  or  it  may  be  too  expensive  or  dangerous  or  inconvenient  to  test  directly.  In  any 
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case,  the  situation  requiring  the  model  is  this;  the  analyst  requires  information  about  the  operation 
of  a  system  that  cannot  be  readily  obtained  from  the  system  itself. 

The  environment  in  which  the  model  is  defined  is  best  chosen  to  optimize  the  desired  result 
of  the  smalysis.  For  instance,  if  the  intent  of  aircraft  design  research  is  to  evaluate  the  ability 
of  a  puticular  design  to  fly,  a  physicsd  model  or  prototype  can  provide  this  information  directly. 
However,  other  factors  also  must  be  considered.  The  type  of  system,  the  cost  of  the  modeling 
process,  and  even  the  predilection  of  the  researcher  also  drive  the  choice  of  modeling  discipline. 

However,  the  explosion  of  computer  technology  in  the  last  thirty  years  has  allowed  simulation 
modeling  to  become  the  principal  method  of  describing  large  amd  complex  systems  ( 16;7).  Dedicated 
high-level  simulation  languages  have  promoted  this  growth,  as  has  the  inherent  flexibility  and  speed 
of  digital  computers 

Model  Tapes  When  a  model  is  required,  a  fundamental  decision  to  be  made  is  what 
type  of  model  will  be  created.  There  is  a  wide  spectrum  of  model  types,  each  with  characteristic 
strengths  and  weaknesses.  A  common  classification  technique  for  model  types  is  to  place  them  on  a 
continuous  scale  according  to  how  they  relate  to  the  real  system  being  modeled.  Closest  to  reality 
are  physical  and  scaled  models.  Physical  models  include  full-scale  mockups  and  prototype  systems. 
Scaled  models  are  common  for  physically  large  systems,  such  as  a  world  globe  modeling  the  Earth 
(15:8) 

Less  concrete  are  analog  models,  which  have  the  same  functionality  as  the  real  system  being 
modeled,  but  are  less  like  it  in  form.  A  graph  is  a  simple  analog  model;  the  length  of  a  line  or  bar  on 
the  graph  is  an  analog  for  some  physical  property,  such  as  time  or  mass.  Further  into  the  abstract 
is  the  compuU-r  simulation,  where  the  representation  of  the  real  object  or  system  exists  only  in 
computer  source  code  and  binary  numbers.  The  least  concrete  of  the  modeling  environments  is 
the  mathematical  model,  where  the  representation  of  the  system  is  described  only  in  mathematical 
or  logical  symbob.  While  this  level  of  abstraction  is  certainly  inexpensive  and  flexible,  oiten  the 
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aasumptions  needed  to  fit  reality  into  this  format  reduces  the  accuracy  and  usefulness  of  the  model 
(15:10). 

Another  consideration  when  choosing  the  type  of  model  is  th-j  need  for  stochastic  properties. 
Most  models  of  real-world  systems  involve  some  uncertainty  in  either  their  input  factors  or  their 
internal  processes.  A  decision  must  be  made  to  either  include  these  stochastic  properties  in  the 
model  or  to  assume  reasonable  deterministic  values  and  avoid  the  issue.  The  model  environment 
must  be  selected  to  accommodate  either  decision  (4:13). 

S.4-S  Simulation.  According  to  Shannon  (15:2),  simulation  is 

...the  process  of  designing  a  model  of  a  real  system  and  conducting  e.xperiments  with 
the  model  for  the  purpose  either  of  understanding  the  behavior  of  the  system  or  of 
evaluating  various  strategies  (within  the  limits  imposed  by  a  criterion  or  set  of  criteria) 
for  the  operation  of  the  system. 

Most  researchers  recommend  a  systematic  approach  to  developing  a  simulation  model,  and  there  are 
frequent  commonalities  between  the  approaches.  EmshofT  and  Sisson  (4:50)  describe  an  approach 
shown  in  flow  caart  form  in  Figure  2.6.  This  sequence  differs  from  that  of  other  authors  such 
as  Pritsker  (11:10)  and  Shannon  (15:23)  in  that  it  emphasizes  the  Ueraitve  nature  of  the  model¬ 
building  process  and  stresses  the  creation  of  subprocesses.  This  incremental  approach  is  useful  for 
large  or  logically  complex  models. 

As  noted  above,  the  computer  simulation  is  a  common  method  of  modeling.  It  is  especially 
useful  when  the  system  being  modeled  involves  stochastic  processes  or  inputs;  with  the  proper 
programming,  the  computer  can  quickly  create  random  variables  with  many  different  distributions. 
The  major  drawback  of  computer  simulation  is  its  high  level  of  abstraction.  In  addition,  the 
translation  of  the  desired  model  into  the  language  of  the  computer  requires  specialized  knowledge 
that  generally  has  nothing  to  do  with  the  environment  of  the  system  being  modeled. 
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Figure  2  6.  Simulation  Model  Development  Sequence  (from  (4;50) 


S.4.3  Operations  Simulation  Models.  The  majority  of  the  research  in  this  area  concentrates 
on  the  modeling  of  manufacturing  or  service  systems.  Manufacturing  systems  models  have  little 
in  common  with  the  operational  control  systems,  as  the  human  element  and  its  unique  qualities 
(dynamic  decision-making,  reaction  times,  the  capacity  to  make  outrageous  errors)  so  integral  in 
operations  is  not  a  major  factor  in  mechanized  manufacturing  processes. 

However,  recent  manufacturing  and  service  system  models  give  an  indication  of  the  “state- 
of-the-art’  of  modeling  in  general.  This  may  lead  to  the  discovery  of  techniques  applicable  to 
operations  modeling.  Medical  facilities,  for  instance,  have  a  complex  operation  with  unique  con¬ 
straints,  and  often  closely  parallels  the  satellite  operations  environment.  A  hospital  pharmacy  in 
Knoxville,  TN  was  modeled  using  SIMAN,  a  modern  personal  computer-based  simulation  language 
(8:91)  The  level  of  detail  was  down  to  simulating  telephone  calls  interrupting  the  pharmacy  em¬ 
ployees  in  their  duties  (8;97).  Another  study  modeled  the  patient  flow  in  a  hospital  outpatient 
center  then  under  construction,  and  its  conclusions  resulted  in  the  redesign  of  the  facility  (17:2C). 
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Research  in  modeling  the  operational  environment  is  generally  directed  toward  the  creation 
and  testing  of  so-called  “expert  systems”.  These  are  computerized  decision-making  assistants, 
that  have  been  “trained”  by  analyzing  the  optimum  decisions  made  by  the  human  operators  and 
creating  a  computet  program  to  model  this  decision-making  process.  The  operators  then  enter  the 
current  situation  into  the  computer  expert  and  this  program  provides  the  necessary  decision  (or 
decision-making  ttid)  more  quickly  and  accurately  than  a  typical  human  operator. 

The  most  significant  current  progress  in  the  design  of  operational  control  systems  is  the 
creation  of  the  Georgia  Tech-Multisatellite  Operations  Control  Center  (GT-MSOCC).  This  facility, 
a  joint  project  of  Georgia  Tech  University  and  the  National  Aeronautics  and  Space  Administration 
(NASA),  is  a  “...real-time,  discrete  event,  interactive  simulator  of  the  operator  interface  to  a  NASA 
ground  control  8y8i..m”  (13:627).  This  complex  model  is  used  to  test  new  control  procedures 
and  mission  subsystems  for  NASA  prior  to  real- world  implementation  It  is  the  key  facility  for 
the  research  into  humam/computer  interaction  and  decision-making  process  for  complex  systems 
(13:636). 

2.5  Scheduling. 

A  major  task  of  satellite  operations  centers  such  as  the  MCS  is  to  optimize  the  use  of  the 
resources  needed  to  accomplish  their  mission.  As  described  above,  the  availability  of  these  resources 
constrain  the  operations  center’s  ability  to  perforin  required  tasks  in  the  required  time  frame.  The 
problem  ;:hen  is  to  find  the  mutually  optimum  time  to  perform  a  finite  number  of  tasks  of  fixed  but 
nonuniform  duration,  which  require  some  limited  set  of  resources.  This  problem  resembles  those 
categorized  in  the  operations  research  discipline  as  “scheduling”  or  “sequencing”  problems.  The 
basic  theory  of  this  class  of  problem  is  described  below,  along  with  common  solution  techniques 
and  problem  examples  similar  to  those  found  in  satellite  operations. 
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S.6  Schtdvling  Theory. 


One  of  the  basic  problems  in  domain  of  operations  research  is  the  sequencing,  or  job-shop, 
problem-  This  class  of  problem  arises  when  the  optimum  order  of  tasks  is  to  be  determined,  with 
each  task  requiring  some  fixed  amount  of  each  of  a  number  of  resources.  The  archetypical  example 
(rmd  the  source  of  the  problem  class’s  name)  is  a  metalworking  shop.  Each  item  of  finished  product 
must  spend  a  fixed  amount  of  time  (dependent  of  the  type  of  item)  on  a  variety  of  machine  tools, 
such  as  lathes,  drills,  punches,  etc.  The  order  in  which  the  items  are  sent  to  the  various  machines  is 
not  fixed.  This  case  is  shown  graphically  in  Figure  2.7(a).  The  problem  then  is  to  find  the  order  or 
sequence  of  item/machine  pairings  that  optimizes  some  specific  performance  measure.  Examples 
of  typical  measures  are  total  production  time  (makespan)  for  one  or  all  items;  machine  tool  idle 
time;  and  total  waiting  time  for  some  number  of  items  to  be  produced  (12:48) 
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If  the  process  requires  each  item  to  be  smoothed,  drilled,  and  punched  an  identical  order 
it  becomes  a  special  case  of  the  job  shop  problem  and  is  called  the  flow-shop  type  problem  (Fig¬ 
ure  2.7,(b)).  A  further  subtlety  is  whether  items  may  skip  ahead  of  others  while  each  item  maintains 
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Figure  2.7.  Job  Shop/Flow  Shop  Schedules  (from  (2:180)) 
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its  proper  machine  sequence.  This  is  called  passing  and  naturally  complicates  analysis  of  flow-shop 
problems  (12:49). 

There  are  a  number  of  criteria  used  for  judging  the  effectiveness  of  schedules.  The  most 
common  is  the  amount  of  time  needed  to  complete  all  jobs  in  the  system.  It  is  generally  desirable 
to  create  a  schedule  to  minimize  this  time,  so  the  criteria  is  called  mtn-makespan.  Another  type  of 
measure  is  the  mean  job  flowtime,  the  average  amount  of  time  jobs  spend  in  the  system.  This  is  a 
good  indication  of  the  congestion  in  the  system.  When  the  jobs  in  a  system  must  meet  specific  due 
dates,  a  measure  of  scheduling  effectiveness  is  tardiness.  This  is  th.  number  of  jobs  whoso  actual 
completion  time  is  after  the  required  completion  time.  The  mean  or  total  time  in  excess  of  the 
required  completion  times  for  the  system  can  also  be  used  (2:223). 

An  extension  of  the  simple  job-shop  problem  is  the  parallel  identical  processor/independent 
job  problem.  The  resource  uniformity  allows  simple  heuristics  to  solve  this  claiss  of  problem  for 
many  scheduling  measurement  criteria.  Iterative  techniques  using  simulation  with  some  form  of 
priority  rules  are  commonly  used  to  solve  these  types  of  scheduling  problems.  Analytical  solutions 
for  problems  with  two  and  three  machines  have  been  discovered.  The  common  solution  method  for 
larger  probler>’s  is  to  use  a  multistage  di  cision  process,  examples  of  which  are  dynamic  proy-am- 
ming,  branch-and-bound  methods,  and  backtrack  programming.  Each  of  these  is  a  form  of  inuli  ' 
enumeration,  that  avoids  complete  enumeration  of  all  existing  schedule  possibilities  (12:49). 
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III.  Methodology 


5.1  Overview. 

The  creation  of  the  MCS  Operations  Center  model  follows  the  strategy  described  in  Sec¬ 
tion  2.4.2  and  shown  in  Figure  2.6  (Page  2-20).  Information  describing  the  processes  to  be  modeled 
and  their  quantitative  output  must  be  collected.  Using  these  data,  measures  of  performance  must 
be  determined,  in  order  to  validate  the  model’s  performance  and  measure  :he  experimental  result 
of  the  model’s  operation.  Once  the  function,  purpose,  and  measure  of  performance  are  known, 
the  model  subsystems  can  be  created,  verihed,  validated,  and  tested.  When  the  subsystems  are 
complete,  they  are  integrated  into  the  whole  This  chapter  describes  in  detail  how  each  of  these 
steps  were  completed  for  this  thesis. 

3.2  Data  Collection. 

Simulating  the  MCS  scheduling  process  and  the  operations  center  task  flow  required  infor¬ 
mation  describing  these  processes.  System  requirement  information  was  needed  to  identify  the 
mission  critical  activities  and  how  these  constrain  schedule  creation  and  operations.  Operational 
data  were  required  to  define  the  activity  flow  internal  to  the  operations  center  and  to  derive  the 
actual  activity  interval  and  duration  time  periods.  Lastly,  historical  records  were  needed  to  per¬ 
form  model  validation.  In  addition  to  the  above  “hard"  data,  informal  interviews  were  conducted 
with  current  and  former  operational  crewmembers  to  provide  initial  face  validation  of  the  overall 
simulation  concept.  The  data  described  as  follows  was  provided  by  the  2  SOPS  to  this  researcher 
during  an  ofTicia!  visit  from  29  June  to  3  July  1992. 

3.2.1  System  Requirements.  System/mis.sioii  requirements  data  were  needed  to  define  the 
constraints  under  which  the  MCS  created  and  performed  the  daily  activity  schedule,  'I  Ic"  overall 
GPS  mission  requirements  are  described  at  the  highest  level  in  the  Navslar  GPS  System  Opera¬ 
tional  Requirements  Document  (SORD).  These  general  re<iuiremcnt.s,  supplemented  by  technical 
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documentation  provided  by  the  GPS  satellite  manufacturer  (Rockwell  International),  were  used 
by  personnel  in  the  2  SOPS  to  create  the  document  called  the  Navstar  Satellite  Support  Require¬ 
ments  (NSSR)  (see  Figure  2.3,  Page  2-15).  The  NSSR  is  the  primary  reference  for  operational 
satellite  contact  requirements.  It  is  utilized  by  2  SOPS  personnel  for  scheduling  future  satellite 
contacts  and  for  prioritization  of  new  satellite  contacts  necessitated  by  real-time  schedule  changes. 
For  each  routine  MCS  activity,  the  NSSR  di^scribes: 

•  whether  an  activity  is  periodic  or  scheduled  “as  needed”, 

•  how  often  scheduled  activities  must  be  performed, 

•  the  expected  activity  duration, 

•  the  activity’s  purpose, 

•  the  time  window  about  the  scheduled  time  in  which  the  activity  must  be  performed,  and 

•  the  rules  to  be  followed  when  rescheduling  the  activity  if  it  cannot  be  performed  at  the 

scheduled  time. 

The  NSSR  provides  most  of  the  information  needed  to  create  a  valid  GPS  satellite  contact 
schedule,  while  the  SORD  puts  the  MCS  requirements  in  the  larger  context  of  the  entire  Global 
Positioning  System.  Both  documents  were  obtained  directly  from  the  2  SOPS. 

S.S.S  Operational  Data.  Information  describing  day-by-day  and  minute-to-minute  MCS  op¬ 
erations  was  required  for  two  retwons.  The  first  was  to  provide  a  detailed  description  of  the  action 
and  interaction  of  the  six  crew  positions  during  each  type  of  MCS  activity.  This  data  allows  the 
simulation  to  include  afunctional  characterization  of  each  position,  so  that  the  effects  of  chaiii.'is  to 
that  position  on  total  MCS  performance  can  be  observed.  Second,  the  stochastic  tendencies  of  ihe 
operations  center  must  be  determined  using  operational  data.  While  the  scheduling  process  can  use 
the  standard  activity  performance  times  described  in  the  requirements  documents,  the  operations 
simulation  requires  the  observed  intervrds  aiul  durations 

The  permanent  record  of  MCS  operations  in  terms  of  discrete  arlivilies  is  mninlaiiied  at 
the  MCS  in  the  form  of  Pass  Plans.  'These  are  detailed  descripliorm  of  the  activities  perfoMiied 
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during  each  satellite  cont8w:t,  including  printouts  of  system  displays  at  the  time  the  activities  were 
performed.  Actual  event  times  can  be  obtained  directly  from  these  displays,  and  the  function  of 
each  crew  position  in  the  performance  of  an  activity  can  be  determined  by  matching  the  tine  and 
type  of  commands  executed  by  that  position. 

Due  to  the  large  number  of  Pass  Plans  generated  by  the  MCS,  only  the  past  30  days  are 
maintained  at  the  MCS.  Pass  Plans  for  65  satellite  contacts  performed  on  2-3  June  1992  (J 152-153) 
were  collected  from  the  2  SOPS.  The  data  spans  all  the  17  satellites  then  operational  and  all  the 
satellite  contact  activities  performed  on  a  daily  basis. 

3. £.3  Hiaiorical  Data.  The  operational  information  described  above  provides  the  informa¬ 
tion  needed  to  structure  the  MCS  model  and  provide  statistical  data  on  the  operations  process. 
In  addition  to  this,  a  case  history  of  MCS  performance  over  some  set  period  of  time  is  required 
to  provide  the  basis  for  model  validation.  If  the  initial  conditions  at  the  beginning  of  that  time 
period  can  be  duplicated,  a  valid  model  should  reproduce  the  actual  MCS  performance  within  a 
predetermined  tolerance  of  error. 

Completed  MCS  activity  schedules,  together  with  the  crew  log  maintained  by  tlie  crew  Flight 
Commander,  completely  describes  the  activities  performed  by  the  crew.  The  schedule  kept  for 
record  is  the  one  the  FCMDR  annotates  with  contact  results,  actual  (as  opposed  to  scheduled) 
contact  start  time  and  duration,  and  contacts  moved  or  added  on  a  contingency  basis  in  response 
to  schedule  changes.  In  addition,  scheduled  and  unscheduled  MCS  computer  and  GA  outages  are 
recorded  on  these  documents. 

The  complete  set  of  Navslar  GPS  Master  Contact  Schedules  and  Crew  Logs  from  31  March 
to  13  May  1992  (J90  to  3134)  were  obtain  from  the  2  SOl’S. 

3. 2. 4  Crewmember  Interview:^,  In  addition  to  obtaining  hard  data  describing  M(-'S  opera¬ 
tions,  personal  and  unstructured  interviewt  were  coinluctccl  willi  the  members  of  an  MC.'S  crew. 
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The  discussions  occured  with  “Bravo”  crew;  Captain  Keith  Dale  was  the  Flight  Commander.  The 
information  obtained,  while  not  directly  applicable  to  the  model  building  process,  contributed  to 
the  overall  direction  of  this  project.  The  results  of  the  interview  is  described  more  fully  below. 

Discussions  with  Captain  James  Serpa,  a  experienced  GPS  Flight  Commander  and  crew 
evaluator  for  that  position,  were  also  used  to  verify  model  details  and  to  provide  additional  "face" 
validation  for  the  model. 

S.2.5  MCS  Performance  Criteria.  A  number  of  operational  criteria  are  used  by  the  2  SOPS 
to  evaluate  the  performance  of  the  Global  Positioning  System.  These  criteria  are: 

•  satellite  vehicle  availability, 

•  Master  Control  Station  availability, 

•  ground  station  availability, 

•  navigational/timing  accuracy  (as  perceived  by  the  system), 

•  operations  personnel  error  rate,  and 

•  satellite  support  success/failure  rate. 

Each  of  these  criteria  has  significance  to  the  system  managers  and  operators.  However,  their 
significance  cannot  be  easily  inter-related,  because  they  impact  (or  may  impact)  different  segments 
of  the  system.  Also,  each  could  have  either  serious  or  negligible  Impact  depending  on  the  relative 
need  of  the  user  community  for  the  system  at  the  time  of  the  occurrence,  and  how  that  community  is 
affected.  Finally,  rating  the  relative  impact  of  these  criteria  on  (iPS  mission  performance  is  difficult 
because  of  the  interaction  of  the  events.  For  instance,  a  personnel  error  may  remove  a  satellite  or 
ground  station  from  service,  then  navigational  accuracy  may  be  affected  when  a  satellite  support 
is  missed.  Although  the  SORD  and  oilier  local  directives  set  the  acceptable  limits  for  system 
availability  and  navigation  accuracy,  the  operational  squadron  by  its  nature  has  a  “zero  tolerance" 
for  deviations  from  perfect  performance  for  all  the  above  measures. 
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Despite  the  difficulties  described  above,  an  accurate  indicator  of  GPS  operations  performance 
can  be  obtained.  The  key  is  using  measurement  criteria  that  are  directly  affected  by  crew  per¬ 
formance.  One  of  these  is  the  satellite  support  failure  rate.  In  the  terminology  of  the  2  SOPS,  a 
scheduled  support  is  called  “MISSED"  if  it  could  not  be  performed  within  60  minutes  after  the 
scheduled  time,  but  is  completed  prior  to  the  maximum  allowable  interval  as  specified  in  the  NSSR. 
A  “FAILED”  support  could  not  be  performed  before  the  time  hmit,  or  could  not  be  performed  at  all 
(3).  Although  not  officially  monitored  by  the  system  managers,  this  discrete  GOOD/MISS/FAIL 
criteria  can  be  extended  to  a  continuous  indicator  by  tracking  hoxu  much  time  passes  until  a  MISSED 
or  FAILED  support  is  completed. 

An  ei  officia  criteria  for  evaluating  the  performance  of  the  MCS  is  ground  antenna  utilization. 
As  described  above  (and  with  the  exception  of  PIKE),  the  GPS  ground  antennas  are  GPS  dedicated 
resources.  Idle  time  cannot  be  used  by  any  other  system,  so  there  is  no  managerial  pressure  to 
maximize  utilization.  However,  when  the  number  of  scheduled  contacts  per  unit  time  is  high  and 
the  system  has  less  scheduling  slack,  real-time  schedule  changes  are  more  difficult  to  resolve  without 
MISSED  or  FAILED  supports.  Currently  there  are  more  than  sufficient  “G A -minutes”  to  allow 
flexible  real-time  rescheduling  (as  is  demonstrated  by  the  low  MCS  satellite  support  failure  /ate), 
but  as  the  satellite  constellation  grows  or  GAs  break,  this  utilization  statistic  will  become  more 
important  to  system  decision  makers.  Even  now,  GA  utilization  is  an  adequate  measure  of  the 
amount  of  slack  GA  resource  available  to  the  system. 

The  MCS  model  described  below  uses  both  satellite  support  success  statistics  and  GA  uti¬ 
lization  as  performance  measures. 

3.S  Model  Development. 

After  MCS  data  was  collected  and  reasonably  sound  ineasureuieiit  criteria  and  indicators 
of  success  determined,  the  preliminary  decisions  regarding  the  type  and  basic  structure  of  the 


MCS  model  could  be  made.  For  each  prospective  type  of  model,  there  are  a  tjumber  of  tradeoffs 
and  amumptions.  These  involve  both  internal  (having  to  do  specifically  with  the  structure  and 
content  of  the  model)  and  external  (concerning  the  development  process  )  factors.  Although  the 
external  factors  would  appear  to  be  irrelevant  to  the  research,  they  had  considerable  impact  on 
the  methodology  and  sequence  of  model  development.  Once  these  decisions  were  made,  and  after 
a  review  of  the  problem  statement  and  the  goals  of  the  project,  development  began  on  the  model 
itself. 


3.3.1  Goals.  In  keeping  with  the  tentative  solution  as  described  in  Chapter  1,  the  overall 
goals  of  the  model  development  process  were  that  the  model  would: 


1.  Utilize  actual  MCS-derived  data  for  initialization  and  operation. 

2.  Reproduce  the  scheduling  and  operations  performance  of  the  MCS  with  maximum  fidelity, 
given  the  fact  that  perfect  fidelity  is  not  possible  due  to  the  non-deterministic  nature  of  the 
scheduling  process. 

3.  Provide  performance  measures  that  are  similar  to  the  mission  effectiveness  criteria  used  by 
the  MCS  management. 

4.  Accommodate  any  set  of  initialization  parameters  that  were  consistent  with  some  past  or 
future  state  of  the  Global  Positioning  System. 

6.  Be  sufficiently  clear  in  construction  and  operation  so  that  maintenance,  follow-on  research, 
or  operational  use  could  be  performed  with  minimum  effort. 


3.3.2  Model  Selection.  Among  the  types  of  simulation  models  briefly  described  in  Chapter  2, 
the  computer  simulation  was  chosen  to  be  the  most  apt.  The  first  reason  for  this  selection  was 
the  desire  to  model  stochastic  activity  durations.  The  two  simulation  languages  available  for  this 
research  (Simulation  Language  for  Alternative  Modeling  (SLAM)  and  SIMSCRIPT  11.5)  allowed 
accurate  modeling  of  this  facet  of  the  operational  environment. 

Another  reason  for  the  choice  of  computer  simulation  was  the  lack  of  clear  analytical  solution 
methodology  for  the  scheduling  problem  presented  by  the  MCS.  The  scheduling  technique  used, 
an  iterative  approach  with  sliding  time  windows  and  changing  priorities,  was  selected  because 
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it  corresponded  to  the  actual  MCS  scheduling  process  This  algorithm  was  not  easily  modeled 
mathematically,  although  an  integer  programming  or  branch-and-hound  technique  might  have  been 
theoretically  possible.  Even  if  the  scheduling  process  could  have  been  performed  analytically, 
there  would  be  interface  problems  with  the  operations  segment  of  the  simulation.  The  scheduler 
would  have  to  be  '■ailed  real-time  when  the  operations  simulation  required  a  new  schedule.  The 
external  scheduler  would  then  have  to  read  the  current  state  of  the  simulation  and  then  provide 
the  new  schedule  in  a  form  usable  to  the  simulation.  These  difficulties  precluded  the  use  of  a 
“mathematically”-ba8ed  scheduler  model  and  led  to  the  development  of  tiie  scheduling  “simulator’' 
described  below. 

S.4  Model  Description. 

3. 41  Overview.  The  following  is  a  detailed  description  of  the  MCS  simulation  code.  The 
source  code  itself  is  provided  in  Appendix  A).  As  the  MCS. SIM  source  code  is  well  documented, 
this  description  will  concentrate  on  fitting  the  individual  routines  into  the  larger  structure  of  the 
program,  and  will  describe  the  rationale  and  logical  basis  for  the  techniques  used.  This  description 
assumes  some  knowledge  of  the  SIMSCRIPT  II. 5  programming  language;  readers  are  referred  to 
the  language  manual  (Bibliography  reference  (7))  for  answers  to  syntax  questions. 

Coding  conventions  were  standardized  and  applied  consistently  throughout  the  program  to 
allow  easier  understanding  and  modification.  These  conventions  are. 

•  A  block  of  asterisks  separate  SIMSCRIPT  routines  and  processes, 

•  Statements  edfected  by  conditional  (IF)  and  flow  control  (DO... LOOP)  constructs  are  indented 
from  the  controlling  statement  for  every  level  of  nesting, 

•  Remarks  precede  the  sections  of  code  they  describe  and  are  inset  to  the  appropriate  level, 

•  Local  variable  names  start  with  a  period(.), 

•  Variables  and  entities  are  UPPERCASE. 
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3.4  t  Initialization  Process.  This  section  describes  the  sequence  of  events  necessary  to  ini¬ 
tialise  the  simulation.  The  initial  conditions  for  the  simulation  run  are  maintained  in  data  files 
external  to  the  program.  This  allows  different  simulation  runs  to  be  made  without  modifying  the 
simulation  source  code.  These  initial  conditions  include  data  that  describes  the  MCS  state  at  the 
desired  simulation  start  time,  the  desired  resource  changes  that  occur  dunng  the  simulation,  and 
operational  parsimeters  that  define  the  limits  of  the  simulation  run.  The  routines  described  will  be 
the  PREAMBLE  and  the  READ.DATA,  READ.VIS,  INIT.GA.USE,  and  INIT.ACTS  routines. 

Reader  familiarity  with  the  following  frequently  used  program  variables  and  entity  attributes 
is  helpful  during  the.  discussion  of  the  program's  operation.  In  some  cases,  the  same  attribute  names 
are  used  with  more  than  one  entity.  “SV”  and  “GA”  are  text  attributes  that  store  the  names  of 
satellite  vehicles  and  ground  antennas.  The  SV  names  are  each  seven  characters,  starting  with 
either  “BlI-”  or  “BI-”  (Block  I  or  ii).  followed  by  a  number  indicating  the  launch  order.  Satellite 
numbers  greater  than  20  indicate  the  satellites  not  yet  operational  at  the  time  data  was  collected 
on  the  system.  “GA  Index"  is  an  integer  assigned  to  each  GA  tc  simplify  the  manipulation  and 
selection  of  ground  antenna  data. 

3. 4- 2.1  PREA  MBLE  Section.  As  with  all  SIMSCRIPT  programs,  the  PREAMBLE 
section  is  u»ed  primarily  to  define  variables  (7:45).  System  resources,  entities,  queues,  and  processes 
are  sdso  defined  and  their  attributes  described.  Of  note  in  the  PREAMBLE  are  DEFINE  statements 
that  set  the  rank  ordering  of  the  queues  used  by  the  scheduling  and  operations  routines.  These 
commands  play  a  critical  role  in  these  processes  and  will  be  explained  in  detail  in  later  sections. 
The  TALLY  statements  create  monitoring  subroutines  that  continuously  collect  statistics  on  system 
variables  relating  to  simulation  performance  (7:240). 

3. 4- 2.2  READ.DATA  Routine.  This  routine  opens  the  default  input  data  file,  of  the 
name  specified  by  the  user  at  program  execution  time.  This  file  contains  the  filenames  of  the  re¬ 
mainder  of  the  input  and  output  files.  The  first  file  in  the  list  (with  filename  assigned  to  the  text 
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variable  TIME. FILE)  is  then  opened.  The  desired  simulation  start  and  end  times  (in  1992  Julian 
day/hours/minutes)  are  then  read,  converted  to  the  number  of  minutes  since  0000  hrs  on  1  Jan¬ 
uary  1992  (henceforth  called  “jminutes”),  and  then  stored  in  the  variables  SIM.START.TIME  and 
SIM.END.TIME.  The  variable  CURRENT.TIME  is  set  to  SIM.START.TIME;  this  will  not  change 
until  after  the  initial  scheduling  is  performed  and  the  simulation  clock  starts.  The  next  values  read 
from  the  file  are  three  simulation  parameters.  NUM.SIMUL. CONTACTS  is  the  maximum  num¬ 
ber  of  simultaneous  satellite  contacts  that  can  be  performed  by  the  MCS  during  the  simulation. 
Technically,  the  most  the  sys.em  can  handle  is  four  (5:7)  .  However,  because  there  are  currently 
only  three  SSO’s  per  operational  crew,  the  practical  limit  is  three.  The  variables  MAX. PRIORITY 
and  INTERVAL. OFFSET. STEP  are  used  by  the  scheduler  in  managing  the  rescheduling  process. 
Finally,  this  routine  creates  the  system  resources  used  in  the  management  of  the  operations  simula¬ 
tion.  Refer  to  Point  A  on  Figure  3.1,  which  is  the  first  of  a  number  of  figures  designed  to  show  the 
operation  of  thesimulatior.  schematically.  Each  labeled  block  represents  a  data  storage  structure, 
either  an  array  or  a  queue.  In  the  case  of  queues,  the  data  are  stored  as  SIMSCRIPT  entities.  The 
simulation  functions  primarily  by  moving  these  entities  among  the  various  queues  at  the  appro¬ 
priate  times.  The  order  in  which  the  entities  are  maintained  and  accessed  is  also  important.  As 
each  entity  has  a  start  time  attribute,  the  entities  are  generally  in  forward  or  reverse  chronological 
order. 


3. 4.2. 3  READ.  VIS  Routine  The  READ. VIS  routine  opens  the  file  indicated  by  the 
VIS. FILE  text  variable  and  reads  data  that  describe  the  time  intervals  when  each  GPS  satellite 
used  in  the  simulation  is  visible  at  each  of  the  selected  ground  antennas.  Each  period  of  visibility 
is  then  stored  as  a  temporary  entity  and  placed  in  a  queue  called  VIS.TABLE.  Refer  to  Point  B  on 
Figure  3.1. 

Any  source  of  visibility  data  can  be  used  to  provide  data  for  this  program.  Initially  this 
routine  contained  the  code  necessary  to  create  the  satellite  visibility  tables  using  ground  station 
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loc{*tion8  and  satellite  orbit  element  sets.  However,  the  complex  and  repetitive  calculations  required 
by  this  method  proved  to  be  time-consuming  to  run  and  difficult  to  code  in  SIMSCRIPT.  The 
practical  alternative  was  to  create  the  data  externally.  The  optimum  source  of  visibility  data  is  the 
MCS-produced  visibility  charts,  especially  when  attempting  to  duplicate  past  MCS  performance. 
However,  this  data  was  not  available  for  the  time  period  used  by  the  simulation,  so  this  research 
used  the  data  produced  by  Pass  Scheduler,  written  in  Pascal  for  MS-DOS-compatible  computers  by 
Kelso  (8).  This  program,  using  standard  two-line  orbits  element  sets  and  the  latitude,  longitude, 
and  elevation  of  the  viewing  location,  calculates  satellite  rise  and  set  times  for  a  specified  time 
period.  The  rc-sults  can  be  saved  as  a  text  file  and  easily  manipulated  to  conform  to  the  input 
specifications  of  the  READ. VIS  routine  (described  below).  The  program  Pass  Scheduler  and  its 
use  with  this  research  is  described  in  detail  in  Appendix  D. 
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The  first  line  of  the  READ. VIS  data  file  is  the  number  of  ground  antennas  used  by  the 
simulation.  The  second  line  contains  the  number  of  days  from  the  start  of  the  year  to  the  start 
of  the  month  being  simulated,  including  1  January  and  excluding  the  first  day  of  the  month.  The 
visibility  data  is  then  read  one  line  at  a  time,  with  each  line  containing  the  data  for  one  SV/GA 
visibility  period.  Each  GA  list,  which  can  contain  any  number  of  satellite  visibility  periods  for  each 
satellite,  is  structured  as  follows  (values  are  separated  by  one  or  more  space); 


•  Line  1: 

-  Name  of  the  GA, 

-  GA  Number. 

•  Line  2  through  n; 

-  SV  name, 

-  Start  visibility  day-of-the-month, 

-  Start  visibility  hour, 

-  Start  visibility  minute, 

-  End  visibility  hour, 

-  End  visibility  minute. 

After  the  final  entry  for  each  set  of  Ground  Antenna  visibility  enttie3,the  word  “END”  followed 
by  five  zeroes  separated  by  spaces  end  the  list  for  that  GA;  the  next  GA  set  (if  any)  starts  on  the 
next  line. 

For  each  line  of  data  containing  visibility  data  read,  a  VIS.EVNT  entity  is  created.  This 
entity  has  five  attributes:  Rise  time.  Set  time,  SV  name,  GA  name,  and  G.\  index.  The  rise  and 
set  times  are  stored  in  jminutes. 

3. 4. 2. 4  JNIT.GA.USE  RouUnt.  The  purpose  of  this  routine  is  to  initialize  the  pre- 
planned  times  when  some  or  all  of  the  GP.S  Ground  Antennas  will  be  unavailable  for  use  during 
the  simulation.  During  the  validation  stage,  this  capability  allows  the  simulation  to  model  the  his¬ 
torical  MCS  and  GA  outages.  For  experiments,  the  outage  data  provides  a  significant  test  variable 
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for  evaluating  system  response.  MCS  total-system  outages  can  be  simulated  by  making  all  Ground 
Antennas  unavailable  for  the  duration  of  the  outage.  Refer  to  Point  C  on  Figure  3.1. 

The  desired  outage  times  are  stored  in  the  datafile  pointed  to  by  the  OUTAGE. FILE  text 
variable.  The  first  two  lines  of  the  file  aje  text  strings  These  strings  allow  the  user  to  describe 
the  contents  or  use  of  the  file;  the  strings  are  reprinted  at  the  end  of  the  simulation  along  with 
the  results  of  the  simulation.  The  next  line  is  an  integer  value  indicating  the  number  of  outage 
description  lines  to  follow.  Each  line  contains  (separated  by  spaces): 

•  the  GA  index  number, 

•  the  GA  outage  start  time  in  jminutes, 

•  the  outage  duration  in  minutes, 

•  the  reaaon  for  the  outage,  in  one  word. 

To  store  the  above  data,  a  two-dimensional  matrix  called  GA. USAGE  is  created.  The  first 
index  is  the  G  A  index  number;  the  second  is  the  simulation  time,  in  minutes  since  simulation  start. 
Each  entry  in  the  matrix  is  a  text  value  (a  “string”  of  characters)  describing  how  each  G  A  is  being 
used  at  each  specific  minute.  These  strings  replace  the  null  strings  (text  variables  containing  no 
characters)  which  aje  the  default  matrix  entries.  For  each  minute  the  GA  is  planned  to  undergo 
maintenance  or  be  otherwise  unavailable,  the  value  of  the  matrix  cell  for  that  minute  and  that  GA 
will  contain  the  one-word  description  of  the  outage.  Unreserved  minutes  will  contain  a  string  of 
ten  space  characters,  which  ate  better  for  output  formatting  than  null  strings 

A  number  of  techniques  were  considered  to  maintain  the  GA  use  record,  including  an  en¬ 
tity/attribute  list  similar  to  the  VIS  TABLE  and  the  use  of  system  resources  to  manage  GA  uti¬ 
lization.  The  large  number  of  table  look-ups  required  made  the  entity  method  too  slow,  while  the 
large  number  of  resource  entities  required  (one  for  each  GA-minute  for  the  duration  of  the  simula¬ 
tion)  stretched  the  storage  capacity  of  the  VAX-implemented  SIMSCRIPT  software.  The  matrix 
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scheme  described  above  is  the  result  of  a  compromise  between  processing  speed,  storage  capacity, 
and  programming  convenience. 

S.4  S.5  INIT.ACTS  Routine.  In  order  for  the  simulation  scheduling  routine  to  sched¬ 
ule  new  MCS  activities  conforming  to  system  requirements,  information  on  previously  performed 
activities  must  be  known.  In  this  simulation,  each  distinct  task  performed  during  a  contact  for  a 
specific  satellite  is  called  an  “ACTIVITY”,  or  “ACT”.  Each  ACT  is  a  SIMSCRIPT  entity.  The  de¬ 
tails  of  the  ACT  required  for  the  scheduling  and  operations  functions  are  maintained  as  attributes 
of  the  ACT  entity.  This  routine  reads  contact  history  data  contained  in  the  file  pointed  to  by  the 
VIS. FILE  variable.  The  data  describes  the  name,  start  time  and  other  details  of  the  most  recent 
(prior  to  the  simulation  start  time)  occurence  of  each  type  of  contact  activity.  For  instance,  only 
the  description  of  the  most  recent  navigation  upload  activity  for  satellite  Bll-OlO  would  be  included 
in  the  input  data  file.  Refer  to  Point  D  on  Figure  3.1. 

After  opening  the  specified  file  for  input,  the  routine  reads  first  the  number  of  satellites 
being  simulated  ilien  the  number  of  individual  activities  to  be  read.  A  permanent  entity  called 
a  MASTER. ACT  is  created  for  each  of  the  activities  to  be  read;  the  input  data  is  then  assigned 
to  attributes  of  these  entities.  The  activity  attributes  fall  into  two  categories;  those  that  remain 
unchanged  during  the  life  of  the  entity,  and  those  that  ate  modified  during  the  simulation.  The 
fixed  attributes  are: 


•  NAME:  Text  label  describing  the  function  f  the  activity.  For  the  basic  simulation,  the  labels 
Me: 


-  NAV  -  Navigation  data  upload, 

-  SOH  -  Satellite  state-of-health  determination,  using  the  satellite  telemetry  data, 

-  NAVBUFF  -  Navigation  processor  data  buffer  dump, 

-  GBDDUMP  -  Global  Burst  Detector  processor  data  dump, 

-  NDUTLM  -  Navigation  processor  real-time  telemetry  examination. 

•  SV:  Text  label  indicating  the  satellite  vehicle  pertaining  to  this  activity.  The  label  consists 
of  the  the  Block  number,  a  dash,  then  the  satellite  launch  number.  Future  satellites  have 
launch  numbers  greater  than  20. 
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•  BLOCK:  The  satellite  Block  number,  either  the  integer  1,  2,  or  3.  Research  and  development 
vehicles  are  Block  I  (1),  the  first  series  of  operational  satellites  ate  Block  II  (2),  and  the  later 
version  of  the  Block  II  SV  is  labeled  (3). 

•  DURATION:  The  expected  duration  of  the  activity  in  integer  minutes. 

•  VARIANCE:  The  variance  of  the  activity  duration.  This  teal  value  is  used  in  the  operations 
sin.  ^'ion  process,  not  in  the  scheduling  process.  Defaults  to  1.0 

•  INI  ERVAL:  The  maximum  interval  between  occurrences  of  this  activity,  in  minutes. 

•  CRITICALITY:  This  integer  value  describes  the  impact  of  this  activity  on  MCS  inis.sion 
completion.  Planned  to  be  used  another  tiebreak  criteria  for  scheduling  conflict  resolution, 
a  system  not  currently  implemented  in  the  simulation  code.  Defaults  to  1. 


The  dynamic  activity  attributes  are: 


•  GA,  GA. INDEX:  After  the  activity  is  scheduled  or  performed,  the  text  attribute  GA  store*- 
the  abbreviated  name  of  the  location  of  the  Ground  Antenna  that  did  or  will  perform  the 
contact.  The  GA. INDEX  attribute  desig.  tes  each  Ground  Antenna  with  an  unique  integer 
number.  The  values  used  in  the  simulalioii  are: 

-  ASCN  (1)-  Ascension  Island 

-  CAPE  (2)-  Cape  Canaveral 

-  DIEG  (3)-  Diego  Garcia  Island 

-  KWAJ  (4)-  Kwajalein  Island 

-  PIKE  (5)  Falcon  AFB,  Colorado  (PIKE  is  the  AFSCN  designation) 

•  START.!  IME:  This  is  the  time  of  either  the  scheduled  activity  performance  (if  after  the 
current  time)  or  the  actual  performed  time  (if  prior  to  current  time).  The  integer  value  is  in 
jrninutes. 

•  NEXT. START  .TIME:  This  attribute  is  used  to  hold  the  tentatively  scheduled  start  tirne  of 
the  next  occurrence  of  this  activity  during  the  scheduling  process.  The  format  is  the  same  as 
START.TIME. 

•  PRIORITY:  This  integer  number  is  the  primary  means  for  decoiiflicting  -'  ctivities  during 
the  scheduling  process.  The  default  is  0,  which  is  incremented  if  this  pctiviiy  conflicts  with 
another  while  being  scheduled. 

•  INTERVAL. OFFSET:  The  scheduling  process  will  allow  activitic.s  that  arc  difficult  to  schedule 
to  exceed  the  maximum  time  between  activity  performance,  if  changing  the  activity  |)riority 
alone  does  not  resolve  the  scheduling  conflict.  This  attribute  stores  the  current  value  (in 
minutes)  of  the  amount  of  excess  interval  allowed.  DefauU-0. 

•  LEAD. TIME  When  an  activity  is  .selected  to  be  scheduled,  the  lime  remaining  from  CUH- 
RENT.TIME  to  the  next  expected  START.TIME  is  calculated  (the  units  an-  minutes)  and 
stored  in  LEAD.'l’lME.  This  value  represents  the  “urgency"  of  scliedulmg  the  next  activity 
of  this  type,  and  can  be  used  to  prioritize  the  activities  >/aiting  to  be  scheduled. 

•  STATUS:  This  text  attribute  describes  the  current  siahes  of  this  activity.  I'lie  permissible 
values  are: 
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-  UNSCHD  -  Unscheduled 

-  SCHD  -  Scheduled 

-  TENT  -  Tentatively  Scheduled 

-  RESC’HD  -  Reschedule 

-  MISSED  -  Activity  has  exceeded  maximum  PP.IORITY 

-  FAILED  -  Activity  has  exceeded  maximum  INTERVAL. OFFSET 

The  newly-created  MASTER. ACT  entities  are  then  filed  in  a  queue  labeled  MASTER;  these 
serve  as  a  permanent  record  of  the  original  activities  and  as  a  tool  for  indexing  when  temporary 
entities  representing  activities  must  be  accessed.  A  set  of  temporary  entities  identical  to  the  MAS¬ 
TER  ACT  entities  is  also  created  at  this  time  and  filed  in  the  queue  PERFORMED.  These  form 
the  starting  reference  for  the  scheduling  routine,  representing  the  activities  performed  just  prior  to 
the  start  of  the  simulation. 

S  -f  S  Scheduling  Procef‘s.  This  section  of  the  MCS  eimiilation  code  creates  a  valid  MCS 
schedule  for  the  period  of  time  from  the  current  simulation  time  to  the  end  of  the  simulation.  The 
MCS  schedule  is  a  chronological  list  of  activities  that  are  to  be  performed.  While  this  simulation 
only  perti.'ns  to  satellite  contact  activities,  the  real  MCS  schedule  also  lists  equipment  outages  for 
maintenance,  system  housekeeping  activities,  scheduled  communication  requirements,  and  so  on. 

For  this  application,  a  “valid”  schedule  is  a  satellite  contact  schedule  that  satisfies  MCS 
operational  constraints  and  either  allows  all  the  NSSR  satellite  contact  requirements  to  be  met 
or  flags  those  requirements  not  attained.  This  models  operational  reality,  as  the  MCS  constraints 
arc  fixed  by  the  MCS  hardware  (i.e.,  number  of  Ground  Antennas)  or  operational  software  (i.e. 
maximum  number  of  satellite  the  system  can  operate).  On  the  other  hand,  the  NS.SR-spccified 
requirements  can  often  i-  stretched”;  generally  there  is  no  concrete  and  immediately  deleterious 
effect  of  exceeding  the  maximum  interval  between  activities  called  out  by  the  NSSR.  Iradeoffs 
can  (and  often  must)  be  made,  such  .as  delaying  a  STATE  OF  HfdVL'TH  activity  on  a  reliable 
satellite  (until  after  its  maximum  interval)  to  allow  a  contingency  NAV  UPLO.\D  activity  to  correct 
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navigation  signal  errors.  The  result  is  that  late  or  missed  activities  do  not  invalidate  a  schedule,  as 
long  as  the  deviations  from  the  system  requirements  is  knov/n. 

In  addition  to  the  above  requirements,  there  are  other  aspects  to  the  schedule  creation  process 
that  must  be  considered.  The  system  requirement  documents  rarely  specify  the  nrinimum  interval 
between  activities,  so  a  valid  schedule  could  be  created  that  would  be  inefficient  due  to  activities 
being  too  frequently  performed.  5>o  activity  intervals  should  be  maximized  inside  the  bounds  allowed 
by  e^'Etem  requirements.  Another  consideration  is  the  question  of  priority.  Given  limited  satellite 
contact  resources  (time,  antenna  availability,  satellite  visibility,  etc.),  there  will  be  instances  where 
satellite  activity  requirements  for  one  or  more  satellites  cannot  be  met.  Which  activity  has  priority 
for  the  available  resources? 

The  scheduling  process  addresses  these  issues.  Three  routines  support  the  scheduling  function: 
MAKE. NEW. ACT,  PRtlSCHEDULE,  and  SCHEDULE. 

3-4  S.l  MAKE. NEW. ACT  Routine.  The  smallest  unit  of  schedulable  time  in  this  sim¬ 
ulation  is  represented  by  the  ACT  entity.  As  will  be  seen  below,  the  presence  of  this  entity  in  a 
particular  queue  is  the  primary  mechanism  of  the  scheduling  process.  As  the  reproduction  of  an 
ACT  entity  is  a  common  requirement  in  the  process,  it  was  efficient  to  create  a  generic  routine  to 
perform  this  function  whenever  required. 

This  routine  is  passed  the  pointer  of  the  entity  to  be  duplicated  by  t  he  calling  routine.  A  new 
ACT  entity  is  then  created,  its  attributes  identical  to  the  original.  The  pointer  to  the  new  entity 
is  then  passed  back  to  the  calling  routine  and  this  routine  ends. 

.3.4.3.S  PRESCHEDULE  Houtine.  Fundamental  to  the  scheduling  prore.ss  is  knowing 
which  activities  need  to  be  scheduled.  This  routine  selects  the  activities  (if  any)  that  must  be 
performed  at  least  once  more  prior  to  the  end  of  the  simulation,  based  on  the  last  time  it  was 
performed  or  scheduled  to  be  performed.  If  there  are  activities  still  to  be  scheduled,  this  routine 
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then  sets  up  the  system  queues  to  the  configuration  expected  by  the  SCHEDULE  routine  and 
calls  that  routine.  If  there  are  no  activities  requiring  scheduling,  it  prepares  the  system  for  the 
operations  simulation  process  and  exits.  The  PRESCHEDULE  routine  uses  the  activities  in  the 
MASTER. ACT  queue  as  means  of  indexing  through  every  SV/activity  pair  exactly  once.  As 
described  above,  there  is  one  entry  in  this  queue  for  each  activity  required  by  each  SV  (for  instance, 
SV  Bll-OlO  will  have  NAV,  NAVBUFF,  GBDDUMP,  and  SOH  activity  entity  in  MASTER.ACT). 
The  INIT.ACTS  routine  also  placed  a  copy  of  each  of  these  entities  in  the  PERFORMED  queue, 
which  is  rank  ordered  by  latest  (i.e.,  numerically  largest)  START. TIME.  For  each  activity  in  turn, 
the  queue  PERFORMED  is  searched  for  the  /«<««<  occurance  of  that  activity  (Point  A  in  Figure  3.2). 


_ 

H  TO  Be  SCHBOUteO  ^ 

UNSCHEDULED 

Figure  3.2.  Prescheduling  Routine 


SIMSTART.TIME 


SIMfND.TlME 


CHANGED 


- ►  REFERJiNCED 


The  status  of  the  found  entity  will  depend  on  when  in  the  simulation  PRESCMF/DULK  ha.s 
called.  At  simulation  start,  the  latest  ACT  entity  is  one  of  those  loaded  at  initialization,  with 
a  START. TIME  prior  to  the  SIM. START  .TIME.  If  the  simulation  ha.s  been  runnin.g  ai;d  a  n<;w 
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schedule  is  required,  the  latest  ACT  would  be  one  that  the  operations  simulation  has  just  performed, 
with  a  START. TIME  indicating  the  simulation  time  the  activity  was  started.  Once  the  desired 
ACT  entity  with  latest  START.TIME  is  found,  it  is  evaluated  to  determine  if  another  activity 
of  this  type  for  this  SV  is  required  in  the  time  frame  of  the  simulation.  This  will  be  true  if  the 
activity  interval  plus  the  interval  offset  plus  the  activity  duration  is  less  than  the  time  remaining 
from  the  last  occurrence  of  this  activity  to  the  end  of  the  simulation  This  is  shown  graphically  in 
Figure  3.3.  In  the  figure,  new  activity  “A”  will  be  scheduled,  while  “B” ,  the  same  activity  but  with 
a  larger  INTERVAL. OFFSET,  would  not  be  scheduled.  Adding  the  activity  DURATION  to  tlie 
previous  START.TIME  prevents  the  system  from  scheduling  contacts  that  cannot  be  completed  in 
the  simulation  time  interval. 


NEXT 


START-I 
TIME  1 


i  i  DURATION  : 

ipmatVAL(ACT^j,  ,j, . 

!  i  1  INTERVAL  OFFSET(ACT) 

^ - - 
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SIM  START  SIM 

START  TIME  END 

TIME  (ACT)  TIME 


Figure  3.3.  Activity  Selection  Timeline 


If  the  activity  must  be  performed  again,  a  copy  of  the  previous  .\CT  entity  is  made.  This  new 
ACT  has  its  STATUS  attribute  changed  to  “UNSCHD”  and  its  LEAD. TIME  calculated.  1  he  values 
of  PRIORITY  and  INTERVAL. OFFSET  are  collected  for  statistical  analysis,  then  reset  to  zero, 
Finally,  the  new  ACT  entity  is  filed  in  the  TO. BE. SCHEDULED  queue  (Point  B  in  Figure  3.2). 

If  the  above  steps  have  been  completed  without  finding  a  candidate  activity  to  schedule, 
the  TO. BE. SCHEDULED  queue  will  now  be  empty  (it  is  always  empty  when  PRESCHEDULK  is 
called).  If  so,  the  scheduling  process  is  complete;  all  the  tentatively  scheduled  activities  have  their 
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STATUS  chamged  to  “SCHD”  and  are  moved  to  the  SCHEDULED  queue.  The  entities  representing 
“FAILED"  supports  remain  in  the  SCHEDULED  queue,  indicating  a  failed  attempt  to  schedule  an 
activity  for  the  time  near  the  value  of  START.TIME.  If  there  are  entities  in  TO  BE  SCHEDULE 
at  the  end  of  PRESCHEDULE,  the  routine  SCHEDULE  is  called  to  attempt  to  fit  these  activities 
into  the  tentative  schedule. 

3.4.S.S  SCHEDULE  Routine.  Once  the  activities  that  require  scheduling  have  been 
determined,  they  must  be  scheduled  in  accordance  with  the  requirements  described  in  the  NSSR 
and  the  constraints  driven  by  system  resources  In  addition,  the  activities  should  be  scheduled 
$martly,  with  consideration  given  to  the  efficient  use  of  system  resources.  The  scheduling  process  is 
basically  sequential  trial-and-error.  The  activities  to  be  scheduled  are  examined  one-by-one  and  the 
optimum  time  to  next  perform  that  activity  is  determined.  Then,  starting  at  that  time  and  moving 
toward  current  time,  the  system  satellite  contact  resources  are  scanned  for  a  suitable  starting  time. 
At  the  first  instance  when  all  the  necessary  resources  are  available  to  perform  the  activity,  the 
search  process  stops.  The  activity  is  then  tentatively  scheduled  for  that  time  and  resources  are 
reserved. 

If  any  one  of  the  current  activities  waiting  to  be  scheduled  cannot  be  scheduled  in  the  al¬ 
lowed  time  window,  all  activities,  both  tentatively  scheduled  and  still  waiting,  are  returned  to  be 
scheduled  again.  However,  the  activity  creating  the  conflict  is  increased  in  priority  so  that  it  gets 
the  first  opportunity  to  reserve  the  needed  resources.  The  entire  process  is  then  repealed.  The 
next  escalation  in  conflict  resolution  occurs  when,  due  to  repeated  conflicts,  the  priority  of  any 
activity  has  been  increased  to  a  predetermined  threshold.  At  that  point,  the  process  “gives  up” 
trying  to  find  a  spot  in  the  schedule  that  meets  the  maximum  interval  requirement.  It  now  tries 
to  schedule  the  activity  to  minimize  lateness.  'I'hc  search  interval  for  that  activity  is  c.xpancled 
slightly  and  the  schedule  process  repeated.  Finally,  if  the  lateness  of  the  activity  reaches  a  set 
maximum  value  without  the  activity  being  succes-sfully  scheduled,  the  scheduling  routine  simply 
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stops  trying.  It  inserts  a  specially-tagged  ACT  entity  to  hold  the  place  of  the  missing  activity  and 
continues  to  schedule  without  the  troublesome  activity.  The  implementation  of  the  above  scheme 
in  SIMSCRIPT  is  described  in  detail  below. 

The  first  step  is  to  remove  the  first  ACT  entity  with  a  STATUS  of  “UNSCHD  ”  from  TO. BE. 
SCHEDULED.  Which  entity  is  first  depends  on  the  rank  ordering  for  this  queue  as  defined  in 
the  PREAMBLE.  During  simulation  validation,  the  ordering  was  optimized  to  minimize  the  dif¬ 
ference  between  the  activity  start  times  as  scheduled  by  this  routine  and  the  times  the  activities 
were  actually  scheduled  by  personnel  at  the  MCS.  The  closest  match  occurred  when  the  entities 
in  TO.BE.SCHEDULED  v'ere  ranked  by  their  high  PRIORITY,  then  low  INTERVAL,  then  low 
START.TIME  attributes.  After  the  entity  is  removed  from  TO.BE.SCHEDULED,  its  attributes 
are  referenced  using  the  entity  pointer  called  ACT  for  the  remainder  of  the  routine.  This  process 
is  shown  as  point  A  on  Figure  3.4. 

Now  the  time  period  over  which  the  “resource  space”  is  searched  is  determined.  This  interval 
begins  at  START.TIME(ACT)  (which  is  the  last  time  this  activity  was  started  for  this  SV),  plus 
the  INTERVAL(ACT),  plus  the  INTERVAL.OFFSET(ACT).  This  is  the  latest  simulation  time  at 
which  this  activity  will  be  tentatively  scheduled.  Thett  stepping  back  to  either  START.TIME  or 
CURRENT.TIME,  whichever  is  later,  each  minute  is  tested  as  a  candidate  starting  time  for  this 
activity.  The  current  candidate  minute  is  stored  in  the  variable  CNCT. START,  shown  as  Point  B 
on  Figure  3.4. 

Once  a  possible  contact  start  time  is  set,  each  VIS.EVNT  entity  (which  define  the  GA/SV 
visibility  periods)  in  VIS. TABLE  is  tested  for:  1)  applicability  to  the  SV  of  this  activity,  2)  visibility 
that  begins  prior  to  the  tentative  contact  start,  and  3)  visibility  that  ends  after  the  duration  of 
the  activity.  The  attributes  of  the  first  VIS.EV'NT  entity  to  meet  these  requirements  (see  point 
C  on  Figure  3.4)  are  referenced  in  the  remainder  of  the  routine  by  the  pointer  VIS.EVNT.  Most 
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Figure  3.4.  Scheduling  Procese  (1) 


importantly,  the  VIS.EVNT  selected  determines  the  GA  (name)  and  GA.INDEX  at  which  the 
tentative  schedule  entry  will  be  performed. 

The  last  check  to  be  made  is  to  ensure  the  Ground  Antenna  referred  to  by  the  VIS.EVNT  is 
not  reserved  by  some  other  activity  or  scheduled  event  (Figure  3.4,  point  D).  The  status  of  each 
GA  is  maintsuned  in  the  GA. USAGE  two-dimensional  text  array.  The  first  index  the  GA  number 
and  the  second  a  count  of  the  simulation  time  in  minutes.  The  minute  index  of  the  array  runs  from 
1  to  SIM. END. TIME  -  SIM. START. TIME  -I-  1,  so  a  correction  is  needed  to  convert  simulation 
time  to  the  array  index.  The  array  index,  .OFFSET,  corresponding  to  the  simulation  minute  being 
examined  is  equal  to  . CNCT. START -t-.t-(SIM. START. TlME-1 ).  One  must  be  subtracted  from 
SIM.START.TIMEto  correct  for  the  fact  that  the  simulation  starts  at  time  zero  but  the  GA. USAGE 
array  starts  with  index  “1”.  To  test  each  minute  from  the  prospective  contact  start  time  through 
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the  duration  of  the  contact,  the  counter  “.t”  is  incremented  from  zero  to  the  DURATION  of  the 
ACT,  as  long  aa  the  .CONFLICT  flag,  earlier  set  to  zero,  stays  unchanged.  For  each  minute,  the 
following  occurs: 

1.  The  target  GA  is  tested  for  previous  use, 

2.  Every  GA  is  tested  for  a  previous  reservation  for  the  SV  being  scheduled, 

3.  The  total  number  of  GAs  reserved  for  satellite  contacts  is  tested  for  exceeding  the  number  of 
simultaneous  contacts  (NUM.SIMUL. CONTACTS). 

If  any  of  the  teats  are  true,  the  .CONFLICT  flag  is  set  and  the  .t  loop  ends  immediately.  This 
condition  results  in  the  program  flow  bypassing  the  “no  conflict"  structure  (described  below).  The 
next  VIS.EVNT  in  the  VIS.TABLE  that  describes  favorable  SV/GA  visibility  (if  any)  is  referenced. 
If  there  is  dual  (or  triple)  visibility,  the  program  again  examines  G A. USAGE  for  those  other ^As  at 
this  simulation  time.  If  all  GAs  visible  to  this  SV  turn  out  to  have  no  free  time  for  this  contact,  the 
VIS.EVNT  loop  ends,  the  .CNCT.START  counter  is  decremented,  and  the  entire  process  repeats 
for  the  simulation  minute  prior  to  the  previous.  This  process  will  continue  until  all  possible  contact 
stut  times  have  been  examined,  or  until  a  place  is  found  in  the  schedule  for  this  activity. 

If  at  any  time  in  this  process  a  suitable  place  in  the  schedule  is  found,  the  attributes  of  the 
ACT  entity  representing  this  activity  are  modified.  The  lucky  CNCT.START  time  is  stored  in 
NEXT.START.TIME,  the  GA  name  and  GA. INDEX  (from  the  VIS.EVNT  entity)  are  stored  in 
like-named  ACT  attributes,  and  STATUS(ACT)  is  changed  to  “TENT”.  When  the  STATUS  is 
changed,  the  do-loops  stepping  through  the  .CNCT.START  times  and  the  VIS.EVNT  list  stop 
indexing  and  fall  though  their  “loop”  statements  to  the  remainder  of  the  routine.  Lastly,  the  SV 
and  NAME  attributes  from  the  successfully  (but  tentatively)  scheduled  activity  are  written  into 
the  GA. USAGE  array  for  the  scheduled  times,  reserving  this  resource  for  this  activity  (F'igure  3.4, 
point  E). 
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If  the  process  described  above  completes  without  finding  a  place  in  the  schedule  for  this 
activity  (shown  as  Figure  3.5,  point  A),  further  steps  are  called  for.  First,  if  the  current  PRI¬ 
ORITY  of  this  entity  is  less  than  the  maximum,  the  PRIORITY  is  incremented  by  the  current 
value  of  .PRIORITY. STEP.  This  variable  increases  as  the  number  of  activities  not  being  sched¬ 
uled  increases,  which  adds  variability  to  the  prioritization  process.  The  entity’s  STATUS  is  then 
chamged  to  “RESCHD”  (to  allow  tracking)  and  the  .RESCHD.FLAG  is  set,  which  later  directs 
the  process  to  bypass  the  PRESCHEDULE  routine  and  repeat  SCHEDULE  with  the  current  but 
subtlety  different  list  of  activities.  If  this  ACT  entity’s  PRIORITY  is  at  or  greater  than  maximum, 
its  STATUS  is  changed  to  missed  and  its  INTERVAL.OFFSET  is  incremented  by  the  value  of 
INCREMENT. OFFSET. STEP.  This  expands  the  search  range  of  the  schedule  process,  with  the 
understanding  that  the  maximum  interval  between  activity  performances  hM  been  exceeded  in  this 
case,  and  the  critical  action  is  to  schedule  the  activity  as  soon  as  possible 

If  after  the  above  operation  the  INTERVAL.OFFSET  value  has  uot  exceeded  one-half  the 
original  INTERVAL,  this  activity  is  placed  back  into  the  TO. BE.  SCHEDULED  queue  (Figure  3.5, 
point  B)  to  try  to  find  a  place  in  the  schedule  the  next  time  SCHEDULE  is  called.  If  the  maximum 
intervaJ  offset  has  been  exceeded,  the  entity  STATUS  is  changed  to  “FAILED”  and  the  FAILED 
variable  is  incremented.  The  activity’s  START. TIME  attribute  is  set  to  the  optimum  simulation 
time  for  this  activity  to  be  performed,  had  it  been  able  to  be  scheduled.  Then  a  copy  of  this  entity 
is  made  (using  the  MAKE. NEW  ACT  routine)  and  stored  in  the  PERFORMED  queue.  This  holds 
the  place  for  this  activity  and  allows  ful^  re  activities  of  this  type  to  be  scheduled  With  a  STATUS 
of  “FAILED”,  this  entity  will  not  be  moved  to  the  SCHEDULED  queue  to  be  performed  by  the 
operations  simulation  process.  The  original  ACT  entity  is  stored  in  the  UNSCHEDULFID  queue 
(Figure  3.5,  point  C),  so  that  it’s  attributes  can  be  examined  during  the  output  pha.se  of  the 
program. 
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S1M.START.T1ME 


SIMENDTIME 


Figure  3.5.  Scheduling  Process  (2) 


If  the  above  process  completes  without  scheduling  conflicts  for  any  reason,  the  tentatively 
scheduled  activities  in  the  TO. BE  SCHEDULED  queue  have  their  new  start  time  (stored  in 
NEXT.START.TIME)  copied  to  the  ST.4RT.TIME  attribute.  The  STATUS  is  set  to  “TENT” 
and  the  entity  moved  to  the  PERFORMED  queue,  where  it  becomes  the  basis  for  planning  the 
next  batch  of  new  activities.  Now  the  TO. BE  SCHEDULED  queue  is  empty,  the  new  set  of  activ¬ 
ities  ate  in  PERFORMED  (but  marked  as  tentative),  and  the  PRESCHEDULE  routine  is  called 
to  determine  whether  further  scheduling  in  necessary.  As  noted  in  Section  3. 4. 3. 2,  if  no  further 
activities  require  new  contacts,  the  tentatively  scheduled  ACT  entities  in  PERFORMED  are  all 
promoted  to  “SCHD”  STATUS  and  moved  to  the  S(”HEDULED  queue  for  input  to  the  operations 
simulation  segment  (Figure  3.6  ). 
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SIM  START.TIME 


SIM. END  TIME 


Figure  3.6.  Scheduling  Process  (3) 


On  the  other  hand,  if  scheduling  conflict  did  occur,  the  attributes  of  the  tentatively  scheduled 
a'  tivities  in  TO. BE. SCHEDULED  are  used  to  erase  their  GA  reservations  in  the  GA. USAGE 
array.  They  then  arc  marked  as  unscheduled  and  the  system  is  back  to  the  state  it  was  in  when 
SCHEDULE  was  first  called,  except  that  the  conflicting  activities  either:  1)  have  new  PRIORITY 
and  therefore  will  be  scheduled  i,i  a  different  order,  2)  have  a  larger  INTERVAL. OFFSET,  allowing 
a  longer  simulation  time  period  to  be  searched,  or  3)  have  been  marked  as  "FAILED”  and  removed 
from  scheduling  consideration.  At  this  point  SCHEDULE  is  called  again  and  the  “old”  entities  in 
TO. BE. SCHEDULED  try  again  for  space  on  the  schedule 

3-4  4  Operations  Simulator  The  task  of  the  operations  simulation  segment  of  the  MCS 
Simulator  is  simply  to  perform  the  MCS  schedule  as  devised  by  ihe  scheduling  process.  Given 
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the  complexity  of  the  activities  performed  and  system  performing  them,  and  the  fact  that  human 
beings  eue  “in  the  loop” ,  some  variability  in  the  performance  of  the  scheduled  activities  is  to  be 
expected.  The  operations  simulation,  in  attempting  to  emulate  the  function  of  the  MCS,  adds  that 
uncertainty.  The  function  is  performed  by  two  processes;  START. OPS  and  PERFORM  ACT. 

S.4-41  START. OPS  Process.  This  segment  of  the  MCS  Simulation  consists  of  two 
processes.  The  first,  called  START. OPS,  takes  no  simulation  time  to  perform  its  function  and 
occurs  once  every  simulation  minute.  STATT.OPS  first  updates  the  variable  CURRENT. TIME  by 
adding  the  time  from  simulation  start  to  SIM. START. TIME.  It  then  checks  for  available  CONTACT 
resources;  there  will  be  NUM.SIMUL.CON  TACTS  (provided  by  the  user  at  initialization)  of  these 
resources.  If  one  or  more  CONTACTS  are  available,  the  next  scheduled  activity  is  selected  (Point 
A  on  Figure  3.7)  and  handed  off  to  the  PERFORM. ACT  proces-s  (described  below).  This  ne.xt 
scheduled  activity  is  the  ACT  entity  in  the  queue  SCHEDULED  with  the  lowest  START. TIME.  If 
the  simulation  end  time  has  not  been  reached,  this  process  then  schedules  itself  to  occur  again  in 
one  simulation  minute. 

S.4.4  S  START-OPS  Process.  Once  an  activity  has  been  selected  to  be  performed,  the 
PERFORM. ACT  process  simulates  the  execution  of  that  activity.  The  first  step  is  10  reserve  one  of 
the  CONTACT  resources  for  the  duration  of  the  process.  The  actual  duration  is  then  determined. 
If  statistical  deviation  from  the  standard  duration  for  this  activity  is  desired,  the  DURATION 
and  VARIANCE  attributes  of  this  ACT  entity  are  used  in  conjunction  with  internal  SIMSCRIPT 
statistical  distribution  functions  to  calculate  a  new  activity  duration.  This  value  is  maintained 
locally  in  the  .DURATION  variable,  and  is  also  written  back  into  the  DURATION  attribute  of  this 
entity  for  “permanent”  record. 

Next,  the  scheduled  start  time  of  this  activity  is  compared  to  the  C.'URRENT.  TIMPi.  If  the 
START. TIME(ACT)  is  greater  the  the  current  time,  the  process  waits  until  the  activity  start  time 
to  continue.  If  the  activity  scheduled  start  time  has  passed,  the  proce,ss  checks  the  VIS.T.\BLE 
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OPERATIONS  (1) 


1  TO  oE  SCHEDULED  | 

1  UNSCHEDULED  1 

Figur<>  3.7  Operations  Process  (1) 


SIM.STARTTIME 


CURRENTTIMK 


SIMENDTLME 


queue  and  GA. USAGE  array  for  sufficient  visibility  and  free  time  at  the  Ground  Antenna  scheduled 
for  this  activity  (labeled  B  on  Figure  3.7).  If  enough  visibility  and  GA  time  is  available  to  perform 
the  activity  beginning  at  the  current  time,  then  the  process  continues  and  the  scheduled  activity 
is  performed  starting  at  the  current  time.  If  the  activity  cannot  be  performed  now  due  to  lack  of 
GA  visibility  or  free  time,  OFF. SCHEDULE  is  set  to  1. 

If  this  activity  can  be  performed  at  this  CURRENT. TIME,  the  .\CT  entity  start  time  is 
changed  to  the  current  time,  the  STATUS  is  changed  to  “PERF” ,  and  the  process  wails  the  number 
of  minutes  specified  by  the  DURATION  attribute.  After  the  wait  is  completed  (DURATION 
minutes  later),  the  process  returns  the  CONTACT  resource  to  the  common  pool  and  files  this 
ACT  entity  in  the  PERFORMED  queue.  If  the  .OFF. SCHEDULE  flag  is  set,  the  current  activity 
cannot  be  performed  at  this  time,  and  the  current  schedule  is  no  longer  valid.  A  new  schedule 
starting  at  the  current  time  and  including  the  activity  that  caused  the  problem  is  required.  So 
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for  every  entity  in  SCHEDUI.ED  with  start  times  at  or  after  the  current  time,  the  GA. USAGE 


reservation  for  that  activity  is  erased  and  the  entity  destroyed  (Figure  3.8).  After  all  are  removed, 
the  PERFORM. ACT  process  relinquishes  its  CONTACT  resource  and  the  PRESCU  i.DULE  routine 
is  called.  PRESCHEDULE  will  start  the  scheduling  process  at  the  CURRENT. TIME,  using  the 
activities  already  performed  by  the  operations  simulation  process  as  “history”. 


SIM.  START  .TI.ME 


CL'RRE.NT.TIME 


SIM  END.TL*/tE 


Figure  3.8.  Operations  Process  (2) 


,1.^.5  Output,  Once  the  scheduling  and/oi  operations  processes  have  complclrd.  the  statis¬ 
tics  r-l'i'  cting  the  perforniaiKe  of  the  simulation  are  ralnilaled  and  saved  for  analysis.  There  are 
five  distinct  output  routines,  to  allow  the  simulation  operator  to  tailor  the  type  and  aiiioiiiil  '>f 
output  lo  the  current  need. 

I  lU'I’OUr.  VIS/RU’OltT.Ql'hl  h'S  Itnutnu  s.  !  h  In.st  routine  dumji.s  the  at¬ 
tributes  of  the  VIS.EV'N  r  entities  in  tin  Vl.S.'l.AUl.E  qeeue.  I  he  ii.se  and  .set  lime.s  c^f  the  satellite 


visibility  is  converted  back  to  days,  hours,  and  seconds  from  the  jminute  format  of  the  RISE. TIME 
and  SET.TIME  attributes.  REPORT  QUEL' ES  performs  the  same  function  for  the  SCHEDULED, 
TO.BE.  SCHEDULED,  PERFORMED,  and  UNSCHEDULED  queues  However,  only  selected  at¬ 
tributes  of  the  ACT  entities  in  these  queues  are  reported.  In  both  cases,  the  data  is  written  to  the 
SIMSCRIPT  default  output  file. 

S.4-5.S  REPORT.  USE  Rouitne.  The  REPORT. USE  routine  outputs  the  contents  of 
the  GA. USAGE  array.  The  result  is  a  table  that  shows  the  minute-by-minute  use  of  eacli  of  the 
Ground  Antennas  for  the  entire  simulation  period.  This  report  also  goes  to  the  SIMSCRIPT  default 
output  file. 


S.4.5.3  ANALYSIS  Routine.  This  routine  provides  the  primary  data  on  the  results 
of  the  simulation  run.  It  makes  extensive  u.sc  of  SlMSCRIPT’s  automatic  statistical  collection 
facilities.  The  output  of  this  routine  goes  to  the  file  whose  name  is  the  contents  of  the  text  variable 
OUT. FILE,  which  is  set  during  initialization. 

Firft,  each  minute  of  the  G A. USAGE  array  for  each  GA  is  scanned  for  the  value  of  the 
array  variable.  Separate  sets  of  variables  are  maintained  for  individual  G.\s  and  for  the  overall 
usaCjC.  The  system  automatically  calculates  statistics  for  these  variables  through  the  use  of  TALLY 
s  atements.  A  list  of  simulation  parameters  are  then  printed  to  permanently  label  the  results  to 
follow.  The  remarks  in  the  GA  outage  data  file  are  read  and  printed  to  further  describe  the  starling 
conditions  for  the  simulation.  A  table  is  then  printed  listing  the  number,  maxiimmi,  minimum,  and 
standard  deviation  of  four  system  variables  being  nioniiored  by  T.ALLY  statements.  “OFFSET” 
and  “PRIORITY”  are  collected  a,s  the  activity  entitie.s  in  the  PERFORMED  are  evaluated  for  the 
need  for  furtlier  scheduling  in  the  PKESCdlEDULK  routiin?.  “GA  UTIL”  and  “GA  RESY”  are  the 
statistics  for  the  variable.s  UTIL  and  RESY  and  were  collected  earlier  in  this  routine,  Hi.stogram.s 
for  the  OFFSET'  and  PRIORITY  variables,  and  then  the  individual  and  total  GA  statistics  are 


reported. 


S.4-5.4  VALIDATE  Routine.  The  scheduling  process  is  validated  by  comparing  the 
scheduling  results  at  a  specific  time  in  the  past  to  the  actual  MCS  schedule  (produced  by  scheduling 
personnel  at  the  2  SOPS)  for  that  time  period.  This  validation  data  is  the  entered  from  MCS  logs 
into  a  file  called  “valact  dat" .  The  format  of  the  file  is  the  same  as  that  for  the  initial  activity  data 
read  during  initialization,  except  that  the  GA  at  which  the  contact  was  historically  performed  is 
included  with  the  other  activity  information.  The  activities  it  contains  are  the  first  of  each  type 
after  the  time  set  as  the  simulation  start.  The  VALIDATE  routine  first  opens  the  validation  data 
file  and  the  first  activity  record  is  read  The  activity  name  and  SV  from  the  validation  activity  are 
used  to  search  for  the  first  (earliest)  similar  activity  in  the  SCHEDULED  queue.  As  there  is  a  one- 
to-one  correspondence  between  the  validation  activities  and  the  scheduled  activities,  a  matching 
activity  will  be  found.  The  absolute  value  of  the  difference  between  the  historical  and  simulation 
activity  start  times  is  recorded.  In  addition,  a  counter  is  incremented  when  the  historical  and 
simulation-scheduled  GAs  match. 

3.5  Validation 

The  first  validation  method  for  the  MCS  model  relies  on  the  expertise  and  experience  of  the 
model-builder.  Each  of  the  subfunctions  of  the  model  were  created  to  duplicate  the  corresponding 
function  in  the  MCS:  Initialization,  Scheduling,  Operations,  and  Reporting.  .\t  each  stage  in  model 
creation,  the  builder  tested  the  subfunctions  and  compared  the  result  to  first-hand  knowledge  of 
how  the  like  MCS  function  operates. 

The  second  methodology  for  the  MCS  Simulation  validation  will  use  detailed  MCS  data  for 
a  period  of  time  prior  to  and  after  some  fixed  date  in  the  past.  Thi.s  date  become.s  the  validation 
datapoint.  The  data  prior  to  validation  time  is  required  to  ‘  hot  start"  the  simulation  in  any  ca.se, 
but  it  also  allows  the  simulation  to  start  with  the  exact  state  of  the  Mt.'S  at  that  instant.  The 


3-30 


MCS  data  after  the  validation  time  is  used  to  provide  the  simulation  the  identical  environmental 
conditions  experience  1  by  the  MCS,  throughout  the  run  of  the  simulation. 

Once  the  simulation  has  been  run,  under  conditions  matching  those  experienced  by  the  MCS 
for  the  same  time  period,  the  simulation  schedule  is  compared  to  the  actual  performance  of  the 
MCS.  Quantitative  measures  are  taken  of  the  differences  between  the  MCS  and  simulation  results. 
The  magnitude  of  the  differences  are  an  indication  of  the  simulation’s  scheduling  “fidelity”,  that  is, 
its  ability  to  reproduce  the  MCS  generated  schedule.  An  exact  reproduction  of  the  MCS  schedule 
would  result  in  zero  difference.  The  measures  do  nol  indicate  the  absolute  scheduling  efficiency 
or  quality  of  either  the  MCS  personnel  or  the  simulation.  The  parameters  of  the  simulation  can 
be  adjusted  to  maximize  the  simulation  fidelity  (by  minimizing  the  measures),  but  considering  the 
vast  number  of  possible  schedules  that  meet  all  the  scheduling  requirements,  a  perfect  match  is  not 
likely. 

S.6  Experimentation 

Once  its  validity  hew  been  tested,  the  MCS  Simulation  will  be  used  to  examine  the  probable 
response  of  the  MCS  to  changes  in  the  operating  environment.  The  applicability  of  the  simulation 
results  to  the  actual  system  largely  depends  on  the  accuracy  of  the  scheduling  process.  If  after  the 
validation  step  the  differences  between  the  simulation  and  human  scheduler  arc  zeroed,  then  the 
experimental  results  could  be  a.ssumed  to  be  representative  of  the  actual  system  response  under  the 
test  conditions.  This  will  not  be  the  case,  so  the  best  that  can  be  assumed  from  the  outset  is  that 
the  test  results  are  consistent  among  themselves.  If  this  can  be  demonstrated,  then  trends  observed 
between  experiment  results  can  be  assumed  to  be  true  also  for  the  MCS,  even  if  the  absolute  results 
cannot  be  compared. 

The  input  parameters  used  for  the  experiments  arc  the  number  of  operational  satellite  vehicles 
and  the  number  of  operational  GF'S  Ground  Antennas.  The  SVs  will  vary  between  IG  (tin;  number 
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used  for  validation)  and  24,  the  maximum  number  of  operational  vehicles  currently  planned.  There 
is  no  plan  to  add  to  the  current  suite  of  five  GAs,  so  the  number  of  operational  G  As  used  for  testing 
will  vary  from  three  to  five.  Each  combination  of  three  and  four  operational  GAs  will  be  tested.  As 
time  allows,  alternative  scheduling  priorities  will  be  tested  to  determine  their  affect  on  simulation 
results. 

As  described  in  Section  3. 4. 5. 3,  the  simulation  results  will  be  a  measure  of  the  scheduling 
effort  and  the  GA  utilization.  These  results  will  be  tested  for  consistency,  correlation,  and  trends. 
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IV.  Analysvi  and  Results 


4.1  Overview. 

During  the  process  of  coding  the  simulation  model  described  in  Chapter  3,  care  was  taken 
that  the  flov/  of  the  program  emulate  the  MCS  operational  process  as  closely  as  possible.  There 
were  two  primary  reasons.  The  first  was  that  this  process  was  well  understood,  and  by  mapping 
the  flow  of  the  code  to  the  function  of  the  MCS,  it  could  be  clearly  seen  that  the  program  was 
executing  as  expected.  Secondly,  having  the  program  execution  process  model  the  MCS  operations 
process  provided  reassurance  that  the  simulation  would  duplicate  the  results  of  the  MCS  with  a 
certain  minimal  accuracy  level.  The  first  reaison  is  related  to  vertficaiion,  the  second  to  validation 
(11:11).  The  results  of  these  two  critical  modeling  steps  are  described  in  this  chapter. 

Once  the  simulation  was  completed,  verified,  and  validated,  a  set  of  experiments  were  designed 
to  exercise  the  model  in  circumstances  similar  to  those  encountered  by  the  MCS  and  provide  data 
for  analysis. 

4.2  Verification. 

In  the  verification  process,  the  concern  is  the  internal  consistency  of  the  model  (15:210). 
This  process  ensures  the  model  has  been  constructed  properly,  according  ihe  the  rules  of  the 
chosen  modeling  environment.  For  physical  models,  this  may  entail  re-measurement  of  critical 
dimensions.  In  mathematical  models,  perhaps  supporting  proofs  are  re-examined  for  validity.  With 
computer  simulation  models,  the  verification  process  includes  a  code  review  and  ‘  debug"  to  ensure 
the  program  parameters  and  logic  are  as  intended 

4.2.1  Verification  Analysis.  For  this  computer  simulation,  verification  include.^  an  exami¬ 
nation  of  the  blMSCRIFT  11.5  source  code  to  ensure  there  are  no  numerical  or  logical  errors.  This 
was  performed  at  the  completion  of  each  SIMSCRIPT  module,  then  again  just  prior  to  the  start 
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of  experimentation.  As  described  earlier,  this  task  was  simplified  by  designing  the  initialization 
routines  to  maximize  the  amount  of  data  stored  external  to  program.  For  the  working  data  created 
by  the  program  during  it’s  operation  but  not  routinely  output,  additional  print  statements  were 
included  in  the  code  during  development  and  validation  to  make  these  values  external.  This  allowed 
not  only  verification  of  the  numerical  correctness  of  internal  variables,  but  also  allowed  the  program 
logic  to  be  examined  in  greater  detail  and  verified.  Most  of  these  statements  were  removed  prior 
to  the  experiment  stage  but  llieir  vestiges  remain  in  the  various  REPORT  routines  retained  in  the 
operational  code. 

As  an  example  of  the  type  of  data  collected  during  verification  and  validation,  the  results  of 
one  early  prototype  run  is  shown  in  Tables  4.1  and  4.2.  The  first  table  shows  the  SIMSCRIPT 
modules  announcing  they  had  been  called  When  the  routine  SCHEDULE  was  manipulating  ac¬ 
tivity  entities,  the  routine  printed  each  action,  the  current  simulation  time,  and  entity  attribute 
data. 


Table  4,1.  Scheduling  Verification/Validation  Sample  Data. 


IIIT.ICTS 

PBSSCISDULE 

senouu 

PUVIOUSLY:  SVIOe/Sapp.l 
B««  kct:  SVIOS/Snpp.t 
■OV;  SVI06/8«pp.l 

PUVIOUSLY;  8VI06/8app.4 
aaa  act:  SVI0e/8app.4 
■0«:  8VIOS/Sii|)p.4 


PIK8CUDULE 

SCHEDULE 

PUVIOUSLY:  SYIOS/Snpp.l 
B«a  act:  BVIOO/Snpp.l 
lOV :  8VI09/Sapp  1 

lOV:  SYBIO/Sopp.l 

PUVIOUSLY:  SVSlO/Snpp  4 
na*  act:  SVSlO/Sapp.4 


(  16/  340)  acbadalad  for  323990 
(  16/  360)  scbadolad  for  .334360 

<16/  360)  achodolad  for  334360  at  IHiJ 
<  13/  360)  achodolad  for  333990 
<  12/  360)  achodolad  for  324337 

(  13/  360)  achadulod  for  334337  at  lUlJ 


(  16/  360)  achadolad  for  333960 

<  16/  360)  schadolad  for  334340 

<  16/  360)  achadnlod  for  324340  at  DIEO 

<  16/  360)  tchadolad  for  324330  at  ISCS 
(  12/  360)  acbadnlad  for  323970 

<  12/  360)  acbadnlad  for  324289 


Table  4.2  shows  one  way  the  operations  simulation  process  was  verified.  As  each  activity  was 
assigned  to  a  different  segment  of  the  operations  task  flow,  output  statements  in  the  code  printed 
the  time  of  the  activity  status  change  and  details  about  the  function  and  the  entity.  As  seen  in 
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Table  4.2.  Operations  VeriRcation  Sample  Data. 


324000  ISSIOI:  Sapp. 4  ,  Sn36  at  PIU  (6).  334012/12  ■intas 

334000  WAIT:  Sapp. 4  ,  sn36  at  PIKE  (S),  324013/13  Biantaa 

324000  ISSiai;  Sapp. 4  .  Sn36  at  KIIJ  (4).  334013/12  Blnataa 

324013  PnrOU:  Sapp. 4  ,  SVI2B  at  IltiJ  (4),  334013/12  Blaataa 
324014  PKKFtU:  Sapp. 3  .  SVS20  at  CAPS  (2),  324014/10  aUatas 
334034  DOSE:  Sapp. 4  .  Sn3fl  at  PIKE  (S) .  324013/13  Blnattl 

3B  Kaackadaliag 

KEPOKT  USE:  Cairaat  tlaa  ■  334034 


the  last  two  lines  of  Table  4.2,  the  operations  routine  also  notified  the  operator  when  it  required  a 
schedule  change,  then  printed  the  status  of  the  system  queues. 

4.S.S  Verificaiton  Results.  The  model  is  technically  verified,  in  light  of  its  error-free  compi¬ 
lation  amd  execution.  Since  all  the  expected  scheduling  and  operational  steps  occurred  as  planned, 
this  verifies  that  the  program  Sgic  is  as  designed. 


4.3  Validation. 

The  goal  of  the  validation  proce&s  is  to  determine  the  fidelity  of  the  model,  how  well  it 
reproduces  the  function  of  the  modeled  system  in  terms  of  the  chosen  measurement  criteria.  The 
MCS  Master  Contact  Schedule  is  the  master  plan  for  all  scheduled  MCS  activities,  so  the  central 
theme  of  the  MCS  model  validation  process  is  how  well  the  model  reproduces  this  key  document. 
In  addition  to  this  validation  method,  the  overall  performance  of  the  model  was  evaluated  by  an 
MCS-experienced  operator.  This  ‘Tace’’  validation  was  top-down,  as  it  occurred  at  each  step  of  the 
model  building  process. 


4-3.1  Validation  Analysis.  Two  validation  principles  were  applied  to  test  whether  the  MCS 
model  faithfully  reproduced  the  performance  of  the  actual  MCS.  The  first  was  applied  both  during 
the  model-building  process  and  after  the  model  was  completed.  This  was  basic  face  validation. 
This  test  asks  if  behavior  of  the  model  agrees  with  that  of  the  real  system,  in  the  opinion  of 
knowledgeable  experts  (4:204).  In  this  case,  the  system  expert  is  also  the  model-builder.  The 


expertise  was  gained  through  three  years  of  association  with  the  GPS  MCS,  as  both  an  operational 
ctewracmbct  and  subsystem  manager.  This  experience  provides  the  a  prion  knowledge-base  from 
which  the  model  was  designed  and  constructed.  This  knowledge  and  experience  is  also  applied  to 
the  logical  analysb  of  the  model’s  output.  During  testing  and  experimentation  of  the  MCS  model, 
the  data  provided  by  the  model  was  continually  examined  for  aptness  and  reasonability.  The  model 
passed  these  validation  tests. 

As  a  second,  more  quantitative  means  of  testing  the  validity  of  the  model,  a  schedule  produced 
by  the  model  for  the  test  date  of  10  April  1992  was  mathematically  compared  to  the  schedule 
produced  and  used  by  the  MCS  on  that  date.  The  hypothesis  was  that  a  model  that  duplicates  the 
MCS  scheduling  process  perfectly  would  produce  the  same  schedule  as  the  MCS,  given  identical 
starting  conditions.  From  the  outset  it  was  understood  that  perfect  fidelity  is  theoretically  possible 
but  practically  very  unlikely.  This  is  due  to  the  very  large  number  of  alternative  schedules  that 
meet  all  the  criteria  of  a  valid  schedule.  Often  in  practice,  when  faced  with  equally  valid  scheduling 
choices,  the  human  scheduler  will  apparently  decide  the  result  arbitrarily.  There  may  be  some 
personal  rule  the  human  uses  to  choose  between  two  similar  choices,  but  the  simulated  scheduler 
has  no  chance  to  duplicate  either  some  subtle  (and  unique)  rule  or  a  “mental  coin-flip” . 

Compounding  this  problem,  once  a  deviation  is  made  in  the  schedule,  the  differences  tend  to 
cascade  with  time.  For  exaunple,  the  human  scheduler  at  1000  hours  has  the  equally  valid  option 
of  using  either  CAPE  or  ASCN  ground  antenna  for  a  30  minute  activity  on  an  SV.  She  chooses 
ASCN  by  some  arbitrary  means.  As  the  scheduling  process  continues,  an  activity  on  another  SV 
with  ASCN  visibility  is  needed  at  1020.  The  earlier  choice  of  ground  station  now  hcis  a  bearing  on 
the  current  decision,  as  ASCN  is  no  longer  available  for  use.  Had  the  earlier  choice  been  CAPE, 
the  alternative  schedule  would  have  ASCN  available.  Over  time,  similar  small  changes  eventually 
result  in  two  quite  different  schedules,  all  due  to  the  decision  made  earlier  in  the  process  Slight 
deviations  in  the  scheduled  time  of  activities  also  has  the  effect  of  causing  subsequent  changes.  For 
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these  reasons,  it  is  not  expected  that  the  MCS  model  can  duplicate  the  scheduling  performance  of 
the  MCS  cchedule  makers  exactly. 

(It  is  important  to  note,  however,  that  the  model  scheduling  algorithm  has  the  capability  of 
producing  better  schedules  than  the  human  scheduler.  A  better  schedule  may  make  more  efficient 
use  of  system  hardware  resources  or  personnel;  may  work  around  system  resource  outages  with 
fewer  “tardy”  activities;  or  may  even  produce  the  same  quality  schedule  in  less  time.  Further 
testing  would  be  required  to  ascertain  the  relative  effectiveness  of  automated  scheduling  methods.) 

Given  an  inherent  and  unavoidable  lack  of  fidelity,  the  validation  test  was  constructed  to 
detect  the  schedule  differences  over  a  short  time  span  on  the  date  selected.  First,  the  activities 
of  the  prior  day  (9  April)  were  collected  from  the  Master  Contact  Schedule  and  entered  into  the 
initial  activity  file  (described  in  Section  3. 4. 2. 5).  Only  the  14  SVs  operational  on  9/10  April  were 
used.  Next,  the  scheduled  GA  and  MCS  outages  that  occurred  on  10  April  (also  taken  from  the 
Master  Contact  Schedule)  were  entered  into  the  OUTAGE.DAT  file.  These  resources  were  “worked 
around”  by  the  MCS  scheduler  and  would  also  have  to  be  handled  by  the  model.  Finally,  the 
data  on  first  activity  of  each  type  for  each  SV  as  really  scheduled  on  10  April  was  entered  into  a 
validation  activity  file.  No  further  activities  would  be  useful  due  to  the  compounding  error  effect 
described  above. 

Under  these  condiiions,  the  validation  run  was  performed  14  times,  each  with  slight  changes 
to  the  primary  scheduling  rule.  The  modifications  changed  the  order  in  which  the  activities  to  be 
scheduled  were  selected  for  insertion  into  the  tentative  schedule.  This  was  done  to  optimize  the 
performance  of  the  model  scheduler  in  terms  of  reproducing  the  MCS  schedule.  This  't  uning’ 
of  the  model  does  not  optimize  the  scheduler  against  some  absolute  criteria;  it  minimizes  the 
difference  between  the  real  system  and  the  model.  The  validation  test  inputs  and  raw  results  are  in 
Appendix  C;  these  results  are  summarized  in  Table  4. .3.  Overall,  the  differences  between  the  various 
ranking  methods  v/ere  negligible,  and  resulted  in  the  minor  reordering  of  scheduled  activities. 
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Table  4.3.  Validation  Results 


Test 

No. 

Priority 

Scheme 

Max 

Offset 

(minutes) 

Min 

Offset 

(minutes) 

Mean 

Offset 

(minutes) 

Offset 

Std  Dev 
(minutes) 

No.  of 
GAs 
Matched 

hP/hL/hl 

0 

41.1404 

40.9769 

23 

hP/hL/ISV 

■SI 

0 

41.1404 

40.9769 

23 

hP/lL/hl 

■SI 

0 

41.9825 

43.0053 

25 

hP/lL/lSV 

0 

41.9825 

43.0053 

25 

6 

hP/lSV/lL 

148 

0 

40.8947 

41.0565 

25 

6 

hP/ISV/hL 

148 

0 

40.8947 

41.0565 

25 

7 

hP/hl 

148 

0 

40.8246 

41.0648 

25 

8 

hP/lI 

148 

0 

40.5965 

40.8355 

26 

9 

hP/hD 

148 

0 

40.5965 

40.8355 

26 

■SI 

hP/lD 

mSSM 

0 

40.8246 

41.0648 

25 

hP/lI/hSV 

■H 

0 

40.6667 

40.8276 

26 

19 

hP/lI/lSV 

0 

40.5965 

40.8355 

26 

19 

hP/lI/hST 

■SI 

0 

41  1404 

40.9769 

25 

11 

hP/lI/lST 

0 

41.4211 

42.6972 

25 

Pfionty  Scheme  K«y 
h  .  High  1  •  low 

P  -  PRIORITY  L  -  LEAD  TIME 
I  •  INTERVAL  SV  •  SV  (name) 
ST  -  START  TIME  D  -  DURATION 


The  Priority  Scheme  column  describes  the  rank  ordering  of  the  activity  entities  in  the  '.^O  .BE 
SCHEDULED  queue.  The  scheduling  process  will  try  to  fit  the  activities  into  the  schedule  in  this 
order.  The  initial  sorting  is  always  by  high  PRIORITY,  to  allow  the  rescheduling  priority  system  to 


operate.  It  was  anticipated  that  high  LEAD. TIME  would  be  the  best  starting  choice  for  the  second 
sorting  level,  as  this  would  allow  the  activities  closest  to  being  tardy  to  be  scheduled  first.  A  third 


sorting  level  was  included  to  allow  further  differentiation  of  the  results.  Fourth  and  greater  levels 


had  no  effect  on  the  outcome  and  were  removed.  The  test  proceeded  by  successively  changing  the 
second  and  third  ordering  criteria  in  an  effort  to  converge  on  the  simulation  result  schedule  that 
best  matched  the  MCS  schedule.  Tests  8  and  9  resulted  in  the  lowest  mean  differential  between 
the  activities  in  the  simulated  versus  MCS  schedule.  Additional  tests  were  then  performed  to  test 
alternative  ordering  arrangements. 
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Table  4.4.  Activity  Types. 


sv 

Block 

Activity 

Name 

Start  Time 
(J  minute) 

Duration 

(minutes) 

Interval 

(minutes) 

I 

SOH 

144375 

10 

II 

GBDDUMP 

144220 

10 

11 

SOH 

144210 

10 

720 

BII-12 

IIA 

NDUTLM 

144175 

10 

720 

II 

NAV 

144950 

15 

1440 

BlOll 

I 

NAV 

144385 

5 

1440 

BIl-01 

II 

NAVBUFF 

144230 

5 

1440 

The  ordering  factors  that  resulted  in  the  best  match,  low  INTERVAL  and  high  DURATION, 
ate  not  independeni.  The  high  dura  ion  activities  generally  have  the  highest  inter-activity  interval. 
The  roason  the  results  are  identical  between  Test  8  and  9  are  that  both  orderings  minimize  the 
interference  between  activities  being  scheduled.  Table  4.4  shows  the  duration/time  characteristics 
for  the  seven  different  activity  types.  Note  that  the  two  activities  with  the  lowest  duration  (Block 
1  NAV  and  Block  II  NAVBUFF)  have  1440  minute  intervals.  This  means  that  whether  the  low 
INTERVAL  or  high  DURATION  ordering  mode  is  selected,  the  simulation  will  generally  schedule 
the  low  INTERVAL  activities  first.  The  chronological  separation  of  the  successively-scheduled 
activities  reduces  contention. 

A  further  indication  of  this  effect  is  shown  by  the  results  of  Test  14.  When  the  START. TIME 
of  the  previously  scheduled  activity  is  used  to  further  sort  the  activities  to  be  scheduled,  the  ability 
of  the  simulation  to  match  the  MCS  schedule  is  reduced.  Table  4.5  on  Page  4-8  shows  this  effect 
in  detail,  by  showing  the  offsets  for  each  activity  in  a  histogram.  The  two  tests  shown,  Test  8  and 
Test  14,  arc  the  best  and  worst,  respectively,  in  terms  of  mean  activity  start  time  diflerential.  As 
stated  above,  the  differences  between  the  test  have  only  a  minor  effect  on  tne  cumulative  statistics. 
The  high  PRIOR ITY/low  INTERVAL  ordering  scheme  was  used  for  the  experimental  runs. 
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Table  4.5.  Validation  Test  Comparison  (Test  8  vs.  Test  14). 


Teat  8 

Test  14 

KlUJUJUM 

No.  of 

Percent  of 

No.  of 

Percent  of 

Activities 

Activities 

Activities 

Activities 

0-10 

20 

35.09 

18 

31.58 

10-20 

7 

12.28 

9 

15.79 

5 

8.77 

3 

5.26 

4 

3 

5.26 

1  50-60 

2 

3.51 

1 

1.75 

5 

8.77 

0 

80-90 

3 

5.26 

2 

3.51 

90-100 

4 

4 

7.02 

100-110 

2 

3  51 

2 

3.51 

110-120 

2 

3  51 

3 

5,26 

120-130 

0 

0 

0 

0 

130-140 

0 

0 

0 

0 

140-150 

2 

3.51 

1 

1,75 

150-160 

0 

0 

0 

0 

160-170 

0 

0 

1 

1.75 

1704- 

0 

0 

0 

0 

4-3.8  Validatton  results.  The  overall  assessment  of  the  validation  results  is  that  the  model 
does  not  reproduce  the  MCS  Master  Contact  Schedule  with  sufficient  fidelity  to  use  the  model  for 
quantitative  comparisons. 

The  model  does  oass  the  face  validation  test,  as  it  does  operate  in  a  manner  comparable 
to  the  MCS  operations  center.  The  schedule  it  produced  during  validation  testing  does  meet 
the  requirements  described  in  tiie  Navstar  Satellite  Support  Requirements  document.  However, 
the  quantitative  results  seen  when  this  schedule  is  compared  numerically  to  the  Master  Contact 
Schedule  cannot  support  the  use  of  the  model  results  for  quantitative  predictions  of  MCS  behavior. 
This  judgement  is  based  on  the  fact  that 


•  the  average  difference  between  57  activities  was  over  40  minutes, 

•  18  of  57  activities  deviated  by  more  than  60  minutes. 
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•  the  validation  test  looked  at  only  the  first  scheduled  activities,  which  would  yield  the  best 
results  the  system  could  produce, 

•  the  large  number  of  deviations  this  early  in  the  sclied uiing  process  would  compound  as  the 
process  continued. 

The  opposite  side  of  this  coin  is  that  the  model  does  perform  as  the  MCS  well  enough  to  make 
general  comparisons  between  the  model’s  and  the  MCS’s  response.  The  successful  face  validation 
indicates  the  pieces  of  the  MCS  are  all  in  the  model.  Flven  though  it  cannot  be  assumed  the 
resulting  numbers  have  meaning,  the  operation  of  the  model  should  result  in  data  thet  will  match 
and  predict  trends  in  MCS  resource  utilization.  On  this  basis,  it  was  decided  to  proceed  with 
experimentation.  The  experimental  results  would  b'  examined  for  indications  that  they  conform 
to  the  expected  performance  of  the  MtJS  (eu;  well  as  is  known).  If  sufficient  parallels  can  be  found 
between  known  or  suspected  MCS  behaviors  and  model  performance,  it  may  be  possible  to  make 
conclusions  about  general  MCS  trends  based  on  the  model’s  output. 

4-4  Eipenmeniatwn. 

The  MCS  model  created  for  this  research  is  not  subtle.  It  is  the  i  mbodiment  of  an  MCS 
high-level  block  diagram.  As  such,  there  are  not  a  huge  number  of  experimental  parameters  that 
can  be  modified  to  perturb  the  model’s  operation.  The  model  is  also  currently  dedicated  to  research 
involving  the  two  major  environmental  factors  that  can  and  will  create  problems  for  the  MCS  - 
the  growing  number  of  satellites  in  the  GPS  constellation  and  the  reliance  on  a  limited  network  of 
ground  stations  to  keep  thos<  satellites  operational.  These  factors  dictate  the  scope  and  direction 
of  experimentation. 

As  described  in  Section  “1.3.2,  the  output  from  the  model  is  presumed  to  be  not  of  sufficient 
quality  to  make  one-to-one  quantitative  predictions.  The  focus  of  experimen' atioii  is  to  determine 
if  the  model  can  at  least  be  used  to  make  general  conclusions  about  MCS  behavior. 
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4-4-i  Kzperimeni  Plan.  The  major  factors  that  caii  be  varied  to  exercise  the  MCS  model 


are: 


1.  the  number  of  active  GFS  satellites  in  the  constellation, 

2.  the  number  of  GPS  Ground  Antennas  available  for  use,  and 

3.  the  number  of  simultaneous  MCS-to-satellite  contacts  possible. 

At  the  validation  date  of  10  April  199‘3,  iiic  war  15  fully  operational  GPS  satellite.s  and  one 
operational  but  undergoing  testing  (Bll-12).  The  15  satellites  broke  down  into  four  aging  Block  1 
(R4iD)  SVs,  nine  Block  II  SV's,  and  two  Block  IIA  SVs.  The  operational  constellation  will  include 
21  aerational  satellites  and  three  operational  spares,  24  total.  The  MCS  is  programmed  to  handle 
as  many  30  satellites  simultaneously,  in  a  mixture  of  Block  1, 11,  and  llA  vehicles.  For  the  purposes 
of  this  experiment,  the  number  of  satellites  was  varied  between  the  current  number  (16)  and  the 
operational  number  (24),  keeping  the  four  Block  I’s  and  adding  eight  Block  lIA  s.  If  the  four 
currently  operational  Block  1  satellites  remain  healthy  and  the  Air  Force  Space  Command’s  goal  of 
six  launches  per  year  is  met,  this  24  satellite  ci.-nliguration  will  occur  sometime  in  1993. 

There  are  currently  no  plans  to  augment  the  number  of  GPS  Ground  Antennas  now  oper¬ 
ational.  However,  it  often  happens  that  one  or  more  GAs  are  unavailable  for  satellite  contacts 
for  extended  periods.  In  the  event  of  a  natural  disaster  or  catastrophic  failure,  any  GA  could  be 
out  of  service  for  days  or  even  weeks.  Another  circumstance  is  that  the  CAPF  G.\  is  reserved  for 
]>rclaunch  compatibility  test  for  days  prior  to  a  GPS  satellite  launch.  So  the  number  of  operational 
GAs  is  an  experiment  parameter.  I..irh  GA  was  rciiiovod  from  the  .lystem  in  turn,  then  removed 
in  pairs.  The  exception  to  this  rule  ic  the  PIKF,  i..\  It  is  a  imicie  case  in  both  the  operation  of 
the  model  and  in  the  experitiicnt  malri.c.  As  a  noii-derlii  iited  f.lPS  resouire,  it  is  tiormally  um  d  fat 
less  Mian  the  remaining  G.\s,  'I'his  is  acconiiteil  for  in  tin-  model  by  making  I'lKl'i  lael  on  the  list 
for  selection  when  the  scheduler  looks  for  open  GAs.  PIKB  also  covers  nearly  tie-  same  coverage 
area  a*  t.  APF,  as  they  are  only  10  degrees  apart  in  latit  ude  and  2.’)  degrees  separated  in  longitude. 
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Therefore,  assuming  PIKE  outages  have  minimal  effect  on  MCS  operations,  it  was  excluded  from 
paired  outage  table.  This  reduced  the  number  of  this  type  of  experiment  from  ten  to  six. 

While  the  MCS  is  designed  to  handle  up  four  satellite  contacts  at  one  time,  the  current 
operational  practice  is  to  have  a  maximum  of  only  three  contacts.  This  is  due  to  crew  manning 
(each  crew  has  three  Satellite  Support  Operator  personnel  trained  and  available  to  handle  routine 
contacts)  and  MCS  computer  system  loading.  Due  to  the  large  number  of  experiments  planned 
with  just  the  number  of  SVs  and  GAs  being  varied,  it  was  decided  to  fix  the  maximum  number  of 
contacts  to  three  and  not  vary  this  parameter  experimentally. 

More  significantly,  the  stochastic  nature  of  the  operations  segment  of  the  simulation  was  not 
included  in  this  set  of  experiments.  This  is  due  m  part  to  insufficient  time  to  perform  experiments 
with  this  facet  of  the  simulation.  However,  the  reason  these  tests  were  of  lesser  importance  was  that 
the  data  collected  at  the  MCS  and  discussion  with  the  MCS  crew  indicated  that  variable  activity 
JuratioiiB  were  not  a  oignificant  MCS  operational  factor.  The  standard  activity  durations  listed  in 
the  NSSR  were  so  conservative  that  seldom  if  ever  did  the  activity  durations  aa  pcifoimed  exceed 
the  scheduled  times  allowed,  In  the  rare  instances  where  this  occurred,  the  variation  wss  due  to 
system  anomalies  that  disrupted  more  than  just  the  activity  being  performed.  The  wide  variety 
of  anomalies  that  create  this  situation  and  their  diverse  effect  on  operations  arc  not  practical  to 
i  'dude  in  this  simple  model. 

The  experimental  suite  required  results  from  12  different  GA  outage  configurations  and  9 
SV  quantities,  for  total  of  108  distinct  runs  of  the  MCS  model.  To  keep  the  simulation  run  time 
reasonable,  the  simulation  length  was  limited  to  -18  hours.  The  initialization  configuration  used 
during  validation  was  the  experimental  Ijascline.  This  coiifiguralion  (orres|)otids  to  tin-  st.ile  of 
the  OCS  sji  of  OOOOZ  10  April  1992.  As  each  SV  was  ad'led  to  the  coiifigiirution,  its  iirtivilies 
on  9  April  were  iiicliidcd  in  the  activity  iiiitiali/ali()n  file,  is  va.s  it's  (iA  v'isiOihty  <l;ita  In  the 
case  of  SVs  not  yet  launched,  an  riclional  activity  history  consistent  with  llie  “real"  activitii  s  wa.s 


created.  The  input  conditions  during  testing  are  described  more  fully  and  the  data  itself  provided 
in  Appendix  B.  The  results  of  the  experiments  are  summarized  in  the  next  section,  in  both  tabular 
and  graphic  formats. 

■^■■^.2  Ezpenmeni  Analysts.  The  data  provided  by  the  experiment  runs  fall  into  two  general 
categories,  based  on  the  measurement  criteria  selected  to  characterize  the  MCS  model  perfor¬ 
mance.  The  first  category  is  data  that  describes  the  activity  scheduling  process  and  the  number  of 
missed/failed  satellite  support  requirements.  The  second  category  of  data  relates  to  the  utilization 
of  OCS  resources,  primarily  the  GPS  Ground  Antennris. 

4-4  2.1  Activity  Scheduling  Analysis.  The  most  significant  indicator  of  the  effect  of 
constellation  size  and  GA  outages  on  scheduling  ability  is  the  number  of  activities  that  could  not 
be  scheduled.  This  number,  along  with  the  total  number  of  activities  scheduled  for  that  experiment, 
is  shown  af  er  the  slash  in  Table  4.6.  No  slash  indicates  there  were  no  activities  that  could  not  be 
scheduler. 


Table  4.6.  Number  of  4c.tivitips  Scheduled/Failed 


IHiH 

\ma\ 

iK&uia 

XAPE 

DIEG 

riKE 

A/D 

^/D 

'  To 

184 

184 

184 

164 

181/3 

184 

IT 

196 

196 

196 

196 

196 

196 

196 

198 

199/1 

193/3 

196 

196 

16 

208 

208 

208 

208 

208 

208 

210 

210/1 

205/3 

208 

208 

to 

220 

220 

220 

221 

22C 

220 

220 

222 

226/1 

2U/3 

222 

220 

232 

732 

233 

232 

232 

232 

234 

238/’ 

231/3 

234 

232 

Kl 

244 

245 

244 

245 

246 

244 

246 

247 

250/j 

245/3 

246 

246 

22 

256 

267 

266 

257 

268 

266 

268 

259 

262/3 

257/3 

258 

269 

23 

26S 

269 

268 

269 

270 

2CS 

270 

271 

274/3 

269/3 

270 

27) 

280 

261 

280 

281 

283 

2MO 

284 

283 

286/4 

284/3 

282 

284, 

As  seen  in  the  NONE  column,  under  optimal  conditions  there  were  12  additional  satellite 
activitio.s  added  to  the  schedule  with  each  -ndditional  .satellite  added  to  tin-  constellation.  As  GA 
resources  were  letr.ovi-d  from  availability,  the  number  of  activities  paradoxically  iiicrciised,  esijecially 
•viicn  the  syst'  in  had  to  <  o|m;  with  a  large  constellulioii.  Follfiw  along  the  bcnloii;  row  of  l  aMe  4.6 
to  see  this  effect.  J  he  reason  this  oicurs  is  the  Hcheduling  algorithm.  'J  he  sysleni  Hchetluh  s  by 
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looking  first  for  the  latest  time  an  activity  can  be  performed.  If  that  time  is  unavailable,  the  system 
“slides”  the  activity  along  the  schedule  looking  for  the  first  earlier  time  resources  are  available  for 
the  activity. 

For  example,  an  activity  is  normally  scheduled  four  hours  apart.  The  system  determines 
the  last  time  this  activity  was  scheduled  and  starts  looking  four  hours  hence  to  schedule  the  next 
occurrence.  If  that  time  is  unavailable,  it  may  have  to  settle  for  a  time  only  three  hours  after  the 
last  occurrence.  The  repetition  rate  of  this  activity  has  thus  increased,  because  the  effective  time 
interval  between  activities  of  this  type  as  scheduled  hsis  decreased.  If  this  happens  four  times  over 
the  48  hour  simulation  period,  the  last  scheduled  activity  of  this  type  will  occur  four  hours  earlier 
than  in  a  schedule  without  conflict.  Thus  there  will  be  “room”  for  the  scheduler  to  add  another 
activity  of  this  type  to  the  schedule,  increasing  the  total  activity  count.  This  effect  can  be  put  to 
use  as  an  indicator  of  scheduling  “stress”,  or  how  much  conflict  occurs  in  the  scheduling  pi.o'.ess. 

Due  to  the  periodic  nature  of  the  scheduled  activities,  the  scheduler  will  not  experience 
continuous  conflict.  The  various  activities  will  occasionally  synchronize  and  for  a  short  period  the 
system  will  have  trouble  finding  resources  to  satisfy  the  scheduling  requirements.  This  situation  is 
shown  clearly  in  Figure  4.1  on  Page  4-14,  which  displays  the  number  of  GAs  utilized  over  simulation 
time.  The  periodic  nature  of  scheduling  “crunches”  is  clear,  with  the  most  serious  problems  coming 
at  about  1400  and  2800  minutes  into  the  simulation.  Note  that  increasing  the  constellation  size 
from  16  to  24  satellites  makes  the  problem  worse;  mo.st  of  the  additional  activities  (doited  lines) 
are  clustered  around  previou'-  clusters. 

Using  the  number  of  activities  scheduled  as  an  indicator,  note  that  both  CAPF  anil  PIKE 
outage's  cause  no  increase  in  stress.  'I  his  i.s  in  t  unexpected,  ^is  thin  (l.\.s  cover  approximately 
the  same  segment  of  the  satellite  orbits  end  can  “cover”  for  eaih  other  (a.s  seen  in  Figure  2.4). 
The  system  first  experiences  noticeable  stress  when  the  Diego  (jari'in  (iA  is  out  anil  there  are  21 
satellites  in  the  constellation.  This  is  expected,  also,  as  DIEG  ha-s  the  least  overlH|i  of  all  the  (.lAs, 


No  GA  outages 


Simulation  Time  (minutes) 

Figure  4.1.  Number  of  GAs  In  Use  vs.  Simulation  Time 


The  system  has  fewer  options  with  DIEG  down.  The  fact  is  reinforced  by  examining  the  dual  outage 
scenarios  in  Table  4.6.  The  only  scenarios  with  activities  failing  to  be  scheduled  involve  DIEG  and 
either  of  the  adjacent  GAs.  (The  number  of  activities  scheduled  in  these  columns  naturally  docs 
not  include  the  failed  supports.)  In  these  dual-outage  scenarios,  scheduling  conflicts  are  greater 
and  begin  earlier  than  with  the  single  outage  scenarios. 

Tie  next  three  tables  describe  other  indicators  of  scheduling  conflicts.  Table  4.7  shows  the 
summed  priority  of  all  the  scheduled  activities.  As  described  in  Section  3  4  3.3  (Page  3-19),  priority 
is  an  activity  entity  attribute  used  to  improve  the  activity’s  probability  of  being  scheduled  in  a 
conflict  situation.  The  higher  the  total  priority,  the  more  conflicts  arc  occurring.  These  values 
give  a  better  indication  of  the  level  of  scheduling  difficulty  for  each  scenario  than  just  the  activities 
scheduled.  Of  interest  in  the  tabic  is  the  fact  that  every  run  h.-.d  to  use  the  priority  system  at  least 
once.  A  review  of  the  raw  simulation  results  showed  that  tliis  occurred  only  20  minutes  into  the 
scheduling  period  in  the  first  scheduling  iteration.  I  'vo  BII-12  activities  were  trying  to  be  scheduled 
for  this  time  while  this  SV  had  visibility  only  at  DIEG.  The  activity  witli  the  low  interval  (SOU) 
had  default  priority,  but  the  other  activity  (NDl!  TbM)  lif'.d  to  start  between  0000  and  0020  hours 
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or  exceed  its  interval  requirement.  The  first  iteration  bumped  the  NDUTLM  activity  ahead  of  the 
SOH  and  both  were  scheduled  during  the  next  scheduling  attempt. 


Table  4.7.  Total  Activity  Priority. 


Ground  Antenna(8)  Unavailable  || 

svs 

NONE 

ASCN 

CAPE 

DIEG 

KWAJ 

PIKE 

A/K 

A/C 

A/D 

K/D 

C/D 

C/K  1 

16 

1 

9 

1 

1 

1 

14 

19 

13 

9 

1 

17 

1 

1 

9 

1 

1 

1 

14 

19 

13 

9 

1 

18 

1 

1 

9 

1 

1 

1 

14 

19 

10 

9 

1 

19 

^^B^B 

1 

1 

9 

1 

1 

1 

14 

16 

19 

9 

1 

20 

1 

1 

9 

1 

1 

14 

16 

19 

9 

1 

21 

11 

1 

9 

1 

1 

11 

32 

25 

28 

9 

1 

22 

11 

1 

9 

1 

1 

11 

32 

25 

28 

9 

1 

23 

^^B^B 

11 

1 

9 

1 

11 

32 

25 

28 

o 

1 

24 

iBBH 

11 

1 

9 

3 

1 

16 

32 

25 

33 

9 

3 

Another  interesting  window  into  the  inner  workings  of  the  .scheduling  algorithm  is  the  decrease 
in  total  priority  in  the  ASCN/DlECi  outage  scenario  as  constellation  size  increases  from  18  to  19. 
Note  on  Table  4.6  that  at  this  point  there  it  an  increase  of  16  activities  scheduled,  the  largest  change 
of  any  for  this  statistic.  What  has  happened  is  that  a  lime  shift  occurred  for  one  type  of  activity 
early  in  the  schedule-building  process  that  has  allowed  subsequent  activities  to  be  scheduled  with 
less  difficulty  than  before.  The  small  increase  in  total  interval  offset  (see  below)  ntay  indicate  a 
scheduling  tradeoff  has  occurred;  one  type  of  activity  being  pushed  very  tardy  while  others  are 
allowed  to  return  closer  to  their  latest  “legar  start  time. 

As  seen  first  in  Table  4.6,  Table  4.7  shows  that  the  scheduler  has  the  hardest  time  when 
DIEG  is  out,  alone  or  with  another  (j'A.  When  two  adjacent  GAs  are  out,  the  difficulty  jieaks. 
While  PIKE  can  pick  up  the  contact  load  when  CAPE  is  out  along  with  DIEG  or  KWAJ,  PIKE 
is  not  much  help  when  ASCN  and  CAPE  are  out  together.  This  is  because  ASCN  and  CAPE  are 
adjacent  and  their  outage  leaves  too  big  a  hole  in  the  coverage.  Note  that  the  priority  level  of 
a  CAPE/DIEG  or  CAPE/KWAJ  outage  stays  fairly  level.  PIKE  utilization  should  be  increasing 
rapidly  during  this  scenario  as  the  constellation  size  grows.  The  dual  coverage  effect  between  PIKE 
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and  CAPE  is  also  seen  in  that  the  CAPfc/DIEG  and  CAPE/KWAJ  total  priorities  are  identical  to 
DIEG  and  KWAJ  alone. 


Table  4.8  shows  the  response  of  the  next  level  of  activity  conflict,  the  interval  offset.  This 
attribute  is  used  to  extend  the  scheduling  window  into  the  “tardy"  time  period,  in  an  effort  to 
schedule  the  activity  after  the  priority  system  has  failed.  The  values  indicate  the  total  number  of 
minutes  the  system  had  to  add  to  scheduled  activities  to  complete  the  schedule.  Failed  activities  are 
not  counted.  Table  4.9  shows  the  maximum  interval  offset  the  system  had  to  apply.  The  synergi.stic 
effect  of  the  ASCN /DIEG  and  KWAJ/DIEG  outages  on  scheduling  difficulty  are  also  seen  in  these 
tables. 


Table  4.8.  Total  Activity  Interval  Offset 


Grouiid  Ant«nna(«)  Un&vail&bU  || 

sv. 

NONE 

ASCN 

CAPE 

DIEG 

KVVAJ 

PIKE 

A/K 

A/C 

A/n 

K/D 

C/D 

C/K 

16 

0 

0 

4i0 

0 

0 

0 

130 

■£3 

980 

0 

17 

0 

0 

4  23 

0 

0 

0 

130 

530 

980 

420 

0 

0 

0 

'•.20 

0 

0 

0 

130 

523 

1120 

420 

0 

0 

0 

.•JO 

0 

0 

0 

130 

540 

1180 

420 

0 

0 

0 

420 

0 

0 

0 

130 

540 

1180 

420 

0 

0 

140 

0 

420 

0 

0 

140 

270 

930 

1390 

420 

0 

■22 

0 

140 

0 

420 

0 

0 

140 

270 

930 

1390 

420 

0 

23 

0 

140 

0 

420 

0 

0 

140 

270 

930 

1390 

420 

0 

24 

0 

140 

0 

420 

0 

0 

140 

270 

930 

1410 

420 

0 

Table  4.9.  Maximum  Activity  Interval  Offset 


r~ 

Ground  AnicnnA(s)  UnftvaiUble  | 

lisa 

System 

ASCN 

CAPE 

DIEG 

KWAJ 

PIKE 

A/K 

A/C 

A/D 

K/D 

C/D 

C/K 

16 

0 

0 

0 

200 

0 

0 

0 

10 

210 

510 

200 

0 

17 

0 

0 

0 

200 

0 

0 

0 

40 

210 

510 

200 

0 

18 

0 

0 

0 

200 

0 

0 

0 

40 

210 

510 

200 

0 

19 

0 

0 

0 

2C0 

0 

0 

0 

40 

210 

510 

100 

0 

20 

0 

0 

0 

200 

0 

0 

0 

40 

210 

510 

200 

0 

21 

0 

70 

0 

200 

0 

0 

70 

70 

390 

510 

200 

0 

22 

0 

70 

0 

200 

u 

u 

70 

70 

OiKJ 

610 

200 

0 

23 

0 

70 

0 

200 

0 

0 

70 

70 

390 

510 

200 

0 

24 

0 

70 

0 

200 

0 

0 

70 

70 

390 

.510 

200 

0 

Activity  Ucheduling  Results.  The  above  data  confirms  the  basic  assertions 
made  earlier  regarding  the  criticality  of  the  Diego  Garcia  GA.  Using  these  results,  system  managers 
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could  rank  the  GPS  GAs  by  least  desirable  to  be  unavailable.  The  order  would  be  (in  order  of  most 
preferable  to  be  unavailable) 

1.  CAPE  or  PIKE  (tie) 

2.  KWAJ  or  CAPE/KWAJ  (tie) 

3.  ASCN 

4.  ASCN/KWAJ 

5.  DIEG  or  CAPE/DIEG 

6.  ASCN/CAPE 

7.  ASCN/DIEG 

8.  KWAJ/DIEG 

From  a  practical  standpoint  it  is  never  preferable  to  have  two  GAs  down  at  the  same  time, 
but  the  simulation  indicates  it  will  be  easier  to  build  a  schedule  (and  of  course  perform  one)  if  both 
ASCN/KWAJ,  ASCN/CAPE,  or  CAPE/KWAJ  were  down  than  if  DIEG  alone  were  unavailable. 
This  is  with  PIKE  fully  available  but  used  only  if  no  GPS-dedicated  resources  are  available. 

These  data  build  a  case  for  the  increased  confidence  in  the  validity  of  the  models  operation. 
The  satellite  contact  scheduling  process  appears  to  react  in  tune  with  the  constraints  placed  on  the 
system  by  the  geographic  location  of  the  ground  stations.  In  addition,  the  scheduling  algorithm 
reacts  logically  to  the  increased  stress  placed  on  the  system  by  the  GA  outages  and  constellation 
build-up. 

4. 4-8.3  Ground  Antenna  Ut)lt!ation  Analysts.  The  overall  system  usage  of  the  GAs  for 
each  experimental  scenario  is  summarized  in  Table  4.10;  the  standard  deviations  of  total  utilization 
are  contained  in  Table  4.11.  The  means  represent  the  mean  number  of  GAs  in  use  for  any  given 
minute  daring  the  simulation,  and  vary  from  a  low  of  0.7000  to  a  high  of  1.1302.  'I'hese  numbers  do 
not  count  the  GAs  unavailable  during  that  experiment.  The  iinians  relate  directly  to  the  number 
of  activities  scheduled  during  that  run,  because  there  are  a  fixed  number  of  GA-minutes  available 
during  the  simulation  run  and  adding  activities  to  the  schedule  use  thc.se  up.  This  is  the  reason 


for  the  regular  increase  in  mean  utilization  as  the  simulated  constellation  grows.  The  standard 
deviations  are  simply  a  confidence  builder;  their  uniformity  is  reassurance  the  model  is  not  off  the 
rails  in  some  fashion  that  is  hidden  by  the  other  indicators. 


Table  4.10.  Mean  Number  of  GAs  Utilized  for  SV  Activities  (per  simulation  minute). 


Ground  Antenna(»)  Unavailable  || 

NONE 

ASCN 

CAPE 

DIEG 

KWAJ 

PIKE 

A/K 

A/C 

A/D 

C/D 

■S&Uil 

16 

0  7132 

0  7132 

0  7132 

0  7132 

0  7132 

0  7132 

0  7132 

0  Vl70 

0.7247 

0  7000 

0  7132 

0  7132 

17 

0.7625 

0  7625 

0  7625 

C.7625 

0  7625 

0.7625 

0  7625 

0  7701 

0  7740 

0  7493 

0  7625 

0.7625 

18 

0.8118 

0  8118 

0  8118 

0  8118 

0  8118 

08118 

0  8118 

0  8194 

0  8309 

0  7986 

0  8118 

0  8118 

19 

0.^611 

0  8611 

0.8611 

0  8649 

0  8611 

0.8611 

0  8611 

0  8688 

0  8840 

0  8556 

0  8688 

0  8611 

70 

0.9104 

0.9104 

0  9104 

0  9142 

0  9104 

0.9104 

0.0104 

0  9181 

0  9333 

0.9049 

0  9181 

0  9104 

21 

0.9597 

0.9635 

0  9597 

0  9635 

0  9674 

0  9597 

0  9674 

0  9712 

0.9826 

0  9618 

0  9674 

0  9674 

22 

1.0090 

1.0128 

1  0090 

1  0128 

1  0167 

1.0090 

1  0167 

1  0205 

1  0319 

1  on  1 

1  0167 

1  0205 

23 

1.0583 

1.0622 

1  0583 

1  0622 

1.0660 

1  0583 

1  0660 

1  0698 

1  0812 

1  0604 

1  0660 

1  0698 

24 

1  1076 

l.lllS 

1  1076 

11115 

1  U91 

1  1076 

1  1229 

1  1191 

1  1302 

1  1212 

1  1153 

1  1229 

Table  4.11,  Standard  Deviation  of  Number  of  GAs  Utilized  for  SV  .\ctivities. 


■■■11 

ASCN 

CAPE 

DIEG 

■  iiV/.PM 

■  at.'45M 

A/D 

K/D 

C/D 

16 

0  8431 

0  8039 

0  7904 

0  7640 

0  8039 

0  7877 

0  7829 

0.7150 

0  7380 

0  7685 

0  7442 

0.7484 

17 

01473 

0  8083 

0.7962 

0  7691 

0.8130 

0  7905 

0  7922 

0  7303 

0  7665 

0  7797 

0  7494 

0  7378 

18 

0  8413 

0.8041 

0.7897 

0  7660 

0  7997 

0  7840 

0  7836 

0.7355 

0  7854 

0  7913 

0.7566 

0.7265 

19 

0  8401 

0  8376 

0  7858 

0,7743 

0  7985 

0  7827 

0  8003 

0  7556 

0  8146 

0  8270 

0.7946 

0  7223 

20 

0  8590 

0  8730 

0.8171 

C  7812 

0.8377 

0  8141 

0.8285 

0.7942 

0.8386 

0  8660 

0  8102 

0  7442 

31 

0  8444 

0  8790 

0  8018 

0.7899 

0  8167 

0  7987 

0  7978 

0  8055 

0.8484 

0  8539 

0  8184 

0  7357 

23 

0  8831 

0.8840 

0.8469 

0.8276 

0  8277 

0  8469 

0.8056 

0.8241 

0.8868 

0  8591 

0  8332 

0,7425 

23 

0  9231 

0.8990 

0  8886 

0  8428 

0  8611 

0  8812 

0  8361 

0  8319 

0.8762 

0  8830 

0  8386 

0  7305 

24 

0  9285 

0.9074 

0  8899 

0  8743 

0  8917 

0  9054 

0  8512 

0  8572 

0  9102 

0  9038 

0  8502 

0  7520 

To  associate  reality  to  experimental  mean  utilizations,  a  similar  calculation  was  made  from 
the  actual  Master  Contact  Schedules  for  15,  16,  and  17  April  1992.  These  days  were  chosen  for  the 
l£u;k  of  apparent  OCS  anomalies  during  this  period  The  GA  contact  durations  for  the  satellites 
and  satellite  tretivities  were  totaled,  with  some  approximations  made  to  account  for  the  presence  of 
non-simulated  activities  mixed-up  in  the  total  contact  duration  With  141  total  contacts  counted 
(each  with  one,  two,  or  three  activities),  the  total  GA  use  came  to  3470  GA-niinutes.  Since  for 
the  three-day  period  analyzed  there  were  1440  minutes/day  *  3  days  *  5  GAs,  there  were  21600 
GA-minutes  available  for  use.  Thus  the  cah  ulated  utilization  rate  for  this  three  day  period  is 
0.1606.  For  the  IB-satellite  simulation  with  no  outages,  there  was  a  mean  of  0.7132  GAs  used  per 
aimulation  minute.  But  with  five  GAs  operational,  each  simulation  minute  =  five  G A-ininute.s, 
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80  the  simulation  GA  utilization  rate  is  0.7132  per  5  GA-minutes,  or  0.1426.  These  numbers  are 
meant  for  general  comparison  only,  as  neither  calculation  method  is  particulewly  rigorous,  but  the 
“ballpark”  figure  indicates  the  simulation  is  operating  as  it  was  designed. 

Page  4-20  through  Page  4-31  show  the  response  of  individual  GAs  to  the  changes  in  both  GA 
outages  and  constellation  size.  A  graph  is  shown  with  each  table  to  assist  the  reader  in  discerning 
trends  and  unusual  behaviors.  Notes  associated  with  each  table  and  graph  highlight  the  salient 
points  of  that  set  and  inter-relationships  between  the  data  shown  and  other  experimental  results. 
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Table  4.12.  Individual  GA  Utilization  with  No  GA  Outages. 


Percentage  of  total  simulation  time 

No  GAs 

ASCN 

CAPE 

DIEG 

KWAJ 

PIKE 

SVs 

in  use 

in  use 

in  use 

in  use 

in  use 

in  use 

16 

50.59 

16.22 

27.74 

13.51 

11.01 

2.85 

17 

47.19 

18.16 

28.47 

13.51 

12.71 

3.40 

18 

42.18 

20.10 

28.47 

13.51 

15.69 

3.40 

19 

39.24 

21.63 

28.68 

16.70 

15.69 

3.40 

20 

36.53 

23.16 

28.68 

17.12 

18.68 

3.40 

21 

32.50 

26.  i5 

28.68 

17.12 

20.63 

3.40 

22 

31.56 

27.99 

29.0G 

18.26 

22.19 

3.40 

23 

31.35 

27.99 

30.52 

20.21 

22.95 

4.17 

24 

29.62 

28.99 

31.46 

20.21 

25.94 

4.17 

Nimber  of  SVi 

Noob  tn  vtfB  ^SCN  •  •  *  CAPE 
.  W&G  ---  •nfc'AJ  — —  PIKE 


Figure  4.2.  (jA  Utilization  -  No  GA  out. 


Thii  M  the  individu&l  GA  utilization  rates  with  no  outages.  The  heavy  black  line  shows  the  percentage  of 
total  simulation  time  there  were  no  G  As  in  use.  This  gives  a  rough  idea  of  the  total  G  A  slack  in  the  system.  CAPE 
GAs  consistently  high  utilization  is  due  to  the  lowi  use  of  PIKE;  activities  in  the  coverage  area  of  both  G  As  will  go  to 
CAPE  first.  PIKE  is  last  in  the  GA  sclfction  priority  to  simulAie  its  AFSCN  schedule  requireinenis.  The  utilization 
of  the  remairiing  GAs  increases  steadily  aa  the  constellation  grows  U  is  possible  that  the  satellite  activities  iiatuially 
“cluster”  (see  Figure  4.1)  while  in  CAPE's  coverage  area.  This  would  explain  CAPE’s  consistently  high  utilization. 
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Table  4.13.  Individual  GA  Utilization  with  ASCN  Out. 


1 _ 

Fercentftfle  of  total 

simulation  time 

Change 

rom  "No  Outage" 

■■a 

KWAJ 

■sii:43H 

No  (jAb 

caPk 

SVs 

in  use 

in  UM 

in  use 

in  uft 

in  use 

in  use 

£k% 

16 

487? 

6.0b 

31  60 

22  22 

IT74 

4  76 

-2  12 

3  86 

8.71 

1  73 

1  91 

17 

45.07 

0  00 

32  33 

24.17 

14  44 

6  31 

-2.12 

3  66 

10.66 

1  73 

1  91 

18 

40  73 

0.00 

32  33 

26.11 

17  43 

8  31 

-1  45 

3  86 

12  60 

1  74 

1  91 

19 

39.27 

0  00 

34  27 

29.10 

17  43 

5  31 

0  03 

5  59 

12  40 

1  74 

191 

20 

37.50 

0  00 

34  65 

29  10 

20  45 

6  84 

0  97 

5.97 

11  S8 

1.77 

3  44 

21 

35  03 

0  00 

35  42 

31  70 

22  40 

6  84 

2  53 

6  74 

14  58 

1.77 

3  44 

22 

32  81 

0  00 

37  26 

32  85 

23.96 

722 

1  25 

8  20 

14  59 

1.77 

3  82 

23 

31  28 

0  00 

38  72 

34.79 

25  10 

7  60 

-0.07 

8.20 

14  58 

2.15 

3.43 

24 

28.99 

0  00 

39.10 

36.74 

28  09 

7  22 

-0  63 

7.64 

16  63 

2  15 

3.05 

1  —  None  tnusfl  ••• 

.  WEO 

1 - KWM 

PIKE 

Figure  4.3.  GA  Utilization  Change  -  ASCN  out. 


With  ASCN  GA  unavailable,  the  adjacent  GA«  (DIEG  to  the  east  and  CAPE  to  the  west)  pick  up  the  slack. 
CAPE  bad  leaa  (lack  to  start,  so  most  of  the  additional  load  falls  to  DiEG.  The  extensive  overlap  of  CAPE  and 
DIEG  into  ASCN  coverage  means  the  slack  is  picked  up  “clean",  with  little  additional  load  slipping  to  KWAJ  and 
PIKE.  The  “None  in  Use”  line  indicates  that  with  20,  21,  and  22  SVs  simulated,  the  system  is  actually  more  efficient 
than  the  baseline  in  terms  of  more  time  with  no  GA»  in  use. 
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Table  4.14.  Individual  GA  'Itilization  with  CAPE  Out. 


Percentage  of  total 

simulat 

ion  time 

Change  from  "No  Outage"  || 

Bifisua 

KWAJ 

■jUiia 

No  Gkt 

sv. 

in  uee 

in  use 

in  use 

in  us 

m  use 

in  use 

A% 

16 

4€  9S 

16  98 

0.00 

14.27 

1.-90 

•3  f>! 

0.76 

0  76 

8  89 

17  32 

17 

43.66 

18  92 

14  27 

21  94 

?1  11 

-3  54 

0.76 

0.76 

9  23 

1771 

IS 

39  62 

20  87 

0.00 

14.27 

24  93 

2111 

-2  56 

0.77 

0.76 

9  24 

1771 

IS 

35.ft2 

22  eo 

0.00 

17.47 

24  $3 

21  n 

-3  42 

0  97 

0  77 

9  24 

17  71 

20 

34  72 

24  13 

17  88 

27  92 

21.11 

-1  al 

0  97 

0  76 

9  24 

17  71 

21 

30.69 

27  12 

17  88 

29.86 

21  11 

-1  81 

0  97 

0  76 

9  23 

17  71 

22 

30.07 

29  34 

0.00 

18  65 

32.19 

-1  49 

1  35 

0  39 

10  00 

17  33 

23 

29.86 

29  34 

0.00 

20  59 

34.20 

-1  49 

1  35 

0  38 

11  25 

17  53 

24 

27  78 

30  90 

0.00 

20  42 

37  19 

22  26 

-1  84 

1  91 

0  21 

11  25 

1809 

Nvand»  SVi  SboulUBd 


— —  ^ocs  to  use  —  ASCN 

WHO 

---  KWAJ  .  PIKE 

Figure  4.4.  GA  Utilization  Change  -  (>APE  out. 


In  this  scenario,  PIKE  picks  up  the  majority  of  the  load  created  by  a  CAPE  outage.  CAPE  and  PIKE  coverage 
overlaps  to  such  an  extent  and  CAPE  leaves  such  a  large  hole  that  the  system  overcomes  its  inherent  reluctance  to 
schedule  activities  at  PIKE.  As  they  are  to  the  east,  ASCN  and  DIEG  are  on  the  “back "  of  PIKE/CAPF-  coverage 
and  the  loading  problem  is  solved  befoie  their  visibility  periods  start  for  the  wc8t'lo<east  travelling  satellites. 


Table  4,15.  Individual  GA  Utilization  with  DIEG  Out. 


1-23 


Table  4.16.  Individual  GA  Utilization  with  KWAJ  Out. 


•imulfttion  tim< 


Li" 

use 

in  use 

in  use 

in  ui 

in  use 

in  use 

33 

31 

It.Ss 

17  22 

30.35 

17.33 

17.33 

0.00 

0  00 

9.10 

11  35 

73 

19.17 

30.35 

17  33 

0  00 

14  34 

IS 

20.69 

30.56 

20.52 

0.00 

14  34 

97 

22  01 

31.88 

20  38 

0.00 

16  77 

at 

04 

24  24 

33  40 

22  33 

0.00 

16.77 

33 

8S 

27.22 

33,40 

2233 

0.00 

18.72 

27 

83 

26.88 

33.75 

2483 

0.00 

21.15 

27 

29 

27  85 

33  96 

24.83 

0  00 

26  28 

InuM  — ^  , 
D*BO  —  PJKB 


Figure  4.6.  GA  Utilization  -  KWAJ  out. 


Althou^  DIEG  picks  up  some  ^ditior.%)  use,  PIKC's  low  utilization  acts  like  a  magnet  to  gather  the  activiiies 
normally  scheduled  for  KWA.  ASCN  use  decreaBcs  slightly  as  some  of  the  previous  KWAJ  (now  PIKE)  activities 
are  satisfied  earlier  and  skip  over  ASCN- 
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Figure  4.7.  GA  Utilization  -  PIKE  out. 


No  GA  hw  to  work  much  harder  to  compensate  for  a  PIKE  outage.  The  system  doesn’t  seriously  require  this 
GA  with  CAPE  available  (a  crucial  “if"). 


Table  4.18.  Individual  GA  Utilization  with  ASCN  and  CAPE  Out. 


Change  from 

"No  Outage'  1 

= 

■craeui 

itWAJ 

PTFE  ■ 

NoGAs 

■iUM 

KWAJ 

uiiisa 

SVi 

in  UM 

in  uM 

in  UM 

in  u« 

in  UM 

in  u«e 

AK 

A% 

A% 

l4  1? 

30  87 

*6.67 

^T99 

10.66 

9.86 

33. 8^ 

38.65 

0.00 

0.00 

36.49 

33  30 

37  32 

-7  54 

12.98 

10.59 

23  82 

36.56 

0.00 

0.00 

38  44 

36  38 

37  33 

■5.62 

14.93 

10.59 

2383 

34.55 

0.00 

0.00 

31  43 

36  38 

29  17 

•4  69 

14  72 

10.59 

25.77 

33.83 

0.00 

0.00 

ai  2S 

3893 

31  63 

-2  71 

14  13 

10  24 

28  33 

30.63 

0.00 

0.00 

33.47 

ai  42 

32  23 

.1.87 

16  35 

10  79 

28  82 

33 

39  31 

0.00 

0.00 

34.24 

33  37 

34  44 

-2.:8 

15.98 

11.18 

31  04 

33 

37  71 

0.00 

0.00 

36.18 

36  35 

34  44 

-3  64 

15.97 

13  40 

30  27 

34 

36.49 

0.00 

0  00 

37  74 

3931 

34.86 

-3.13 

17  53 

13  37 

30  69 

Figure  4.8.  GA  Utilization  -  ASCN  and  CAPE  out. 


With  both  ASCN  and  CAPE  out,  PIKE  is  brought  to  high  utdization,  together  with  major  increaaea  in  the 
remaining  GAi. 
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Table  4.19.  Individual  GA  Utilization  with  ASCN  and  DIEG  Out. 


r  ~ 

Percentage  of  total  eimulation 

time 

Change  from  “No  Outage"  || 

■CRXeLTl 

■ss^ 

■  UltleH 

ICWAJ 

■  UI145M 

No  GAs 

CAPE 

KWAl 

II  sv. 

in  use 

in  uae 

in  use 

in  ue 

in  use 

in  use 

£i% 

A% 

cy% 

<3% 

4511 

40  69 

Oo 

20.28 

11.60 

12  65 

917 

8.76 

41  81 

0.00 

43.26 

0  00 

21  98 

12  IS 

-6  38 

14  79 

9  27 

8.75 

38  51 

0.00 

44  83 

0  00 

25  35 

12.92 

-3.67 

16  36 

9.66 

9.62 

WM 

38.77 

o.co 

45  38 

0  00 

27  19 

15  83 

-2.47 

16  70 

11  60 

12.43 

20 

0.00 

46  91 

0  00 

30  69 

15  83 

-1  50 

16  23 

11  91 

12  43 

21 

33  13 

0.00 

47.67 

0  00 

34  38 

16  22 

0  63 

16.99 

13  75 

12  82 

22 

32  01 

0.00 

49.90 

0.00 

36.94 

1736 

0  46 

20.84 

13  76 

13  96 

23 

28.85 

0  00 

52.71 

0.00 

36  94 

19  48 

-2.60 

22.19 

12  99 

16  31 

24 

28.09 

0  00 

52  01 

0  00 

39  83 

21  18 

-1.53 

20.66 

13.89 

17.01 

Nunbar  of  SVf  Staouteted 


I - Nomtlluw-—  diSre  - KWAJ  - PIKE 


Figure  4.9.  GA  Utilization  Change  -  ASCN  and  DIEG  out. 


As  Table  4.6  shows,  with  this  pair  unavailable  the  system  experiences  major  scheduling  problems.  CAPE 
exceeds  60%  utilization  trying  to  compensate  for  the  outages.  This  is  the  first  scenario  where  any  G.A  exceeds  even 
40%.  PIKE  coverage  overlaps  ASCN  slightly  and  DIEG  not  ut  all,  so  its  low  utilization  cannot  save  the  lay. 
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T&ble  4.20.  Individual  GA  Utilization  with  ASCN  and  KWAJ  Out. 


1^— jBB!SIg^iwramivii3S3BSa— — 

ChatHRe  from 

lU  rfa  •  m  i  1 

Sflixea 

KWAJ 

PIKE 

■cat&xi 

msagia 

■  »ll3tcM 

PIKE 

SVs 

in  uM 

in  use 

in  use 

in  US 

in  use 

in  use 

£k% 

A% 

A9t 

16 

TTSS 

0.00 

3775 

"TTsg 

0  00 

11  60 

24 

6.50 

11  98 

8.75 

17 

•3.33 

0  00 

34.97 

27  43 

0  00 

13  85 

a3.S6 

13  92 

18 

38.93 

0.00 

34  97 

39  37 

0.00 

16  84 

.3  26 

6.60 

16.86 

13.44 

19 

3681 

0  00 

36.63 

33  36 

0  00 

17  22 

•  2.43 

7.85 

15  66 

13.82 

30 

3«.49 

0.00 

36.33 

32  78 

0.00 

21  94 

7.64 

15.66 

18  54 

31 

39  79 

0.00 

37  85 

36  94 

0  00 

21  94 

-2  71 
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Figure  4.10.  GA  Utilization  Change  -  ASCN  and  KWAJ  out. 


PIKE  does  better  at  covering  a  KWAJ  outage  than  a  uIEG  outage,  so  the  system  can  this  scenario  with  more 
grace.  CAPE  ihouldera  ASCN's  load  and  DIEG  filU  in  the  gaps  on  both  sides. 
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Table  4.21.  Individual  GA  Utilization  with  CAPE  and  DIEG  Out. 
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Figure  4.11.  GA  Utilization  -  CAPE  and  DIEG  out. 


The  CAPE  outage  “forces"  the  reluctant  PIKE  to  take  a  fair  share  of  the  load,  which  reduces  the  additional 
load  on  ASCN  and  KWAJ  to  reeuonable  levels. 
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Table  4.22.  Individual  GA  Utilization  with  CAPE  and  KWAJ  Out. 
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Figure  4.12.  GA  Utilization  -  CAPE  and  KWAJ  out. 


PIKE  U  the  only  altemitive  for  scheduling  activities  for  nearly  hiJf  of  the  satellite's  orbit.  The  system  would 
have  scheduling  problems  with  ttiis  scenario  if  PIKE  use  was  not  close  to  zero  in  the  baseline.  As  such,  the  system 
handles  this  setup  better  than  any  other  dual  outage,  and  better  even  than  a  DlEG-alone  outage. 
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Table  4.23.  Individual  GA  Utilization  with  DIEG  and  KWAJ  Out. 
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Figure  4.13.  GA  Utilization  -  DIEG  and  KWAJ  out. 


With  PIKE,  CAPE,  and  ASCN  clustered  into  approximately  90o  of  longitude,  this  scenario  opens  the  largest 
gap  in  the  coverage.  As  indicated  earlier,  the  system  has  the  most  failed  supports  and  the  highest  tardiness  while 
trying  to  compensate.  ASCN  is  pushed  to  nearly  the  same  utilization  than  with  CAPE  and  DIEG  out,  while  CAPE 
and  PIKE  stttys  under-utilized  due  to  their  westerly  position  relative  to  the  outage 
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Pages  4-34  through  4-37  show  the  percentage  of  total  simulation  time  the  system  operates 
with  zero,  one,  two,  and  three  GAs  in  simultaneous  use.  Note  that  even  with  the  simulated  24 
satellite  constellation,  the  are  three  GAs  (and  thus  three  Satellite  Support  Operators)  in  use  only 
8.68%  of  the  time  at  most.  Nearly  70%  of  the  time  there  is  less  than  two  GAs  in  use.  If  the  validity 
of  the  model  could  be  improved  to  the  extent  these  values  could  be  assumed  to  reflect  actual  usage, 
they  could  be  used  by  management  to  aid  workload  planning  and  personnel  scheduling. 

One  interesting  deviation  in  the  otherwise  consistent  data  is  that  with  ASCN  unavailable  and 
the  constellation  size  between  19  and  22,  three  GAs  are  in  use  more  and  one  GA  in  use  significantly 
less  than  in  the  other  single-outage  scenarios.  It  appears  that  with  ASCN  out  the  system  the 
scheduler  must  cluster  the  activities  slightly  more  than  the  other  scenarios.  This  is  also  indicated 
by  the  higher  “none-in-use”  percentage  during  these  same  experiments.  Figures  4.14  and  4.15  show 
this  eftect  graphically.  These  graphs  show  the  change  in  the  number  of  GAs  utilized  for  the  ASCN 
and  CAPE  outage  scenarios  over  the  baseline  no-outage  condition  (the  CAPE  outage  scenario 
was  chosen  as  a  representative  example).  Both  graphs  compare  the  utilization  for  21  simulated 
satellites.  Note  the  higher  number  and  wider  range  of  GA  utilization  changes  for  the  ASCN-out 
over  the  CAPE-out  scenario,  and  the  “clumping”  of  the  ASCN-out  changes  at  regular  intervals 
(Figure  4.14). 


Table  4.25.  Percent  of  Total  Simulation  Time  with  One  G  A  In  Use. 


Figure  4.17.  Percentage  of  Time  One  GAs  in  Simultaneous  Use, 


Table  4.26.  Percent  of  Total  Simulation  Time  with  Two  GAs  In  Use. 
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Figure  4.18.  Percentage  of  Time  Two  GAs  in  Simultaneous  Use. 
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4.19.  Percentage  of  Time  Three  GAs  in  Simultaneous  Use 


Ground  Anienna  Uitlizaiion  Reaults.  As  with  the  activity  scheduling  results, 
the  Ground  Antenna  utilization  rates  under  the  varying  experimental  conditions  confirm  the  proper 
operation  of  the  MCS  model.  Mean  utilization  in  the  simulation  is  within  13%  of  the  sample  value 
for  the  '•eal  MCS  GA  utilization  calculated  from  MCS  logs.  The  simulated  effects  of  single  and 
dual  GA  outages  on  the  utilization  of  the  remaining  Ground  Antennas  are  consistently  explained 
by  the  geographical  arrangement  of  the  GAs  and  their  coverage  areas. 

The  variations  in  the  percentage  of  GAs  in  use  for  each  scenario  arc  consistent  and  logical. 
The  results,  along  with  crewmember  loading  studies,  could  be  used  to  justify  changes  to  crew 
manning,  as  an  SSO  and  other  crewmembers  are  “in  use”  to  the  same  degree  the  GAs  are  in  use. 
The  results  also  add  more  weight  to  the  conclusion  that  the  model  is  functioning  in  a  manner 
similar  to  the  MCS  and  consistent  with  current  MCS  operations. 


V.  Conclusions/ Recommendations. 


5,1  Conclusions. 

The  ultimate  source  for  the  direction  and  implementation  of  this  research  was  the  problem  of 
giving  the  Global  Positioning  System  planners  and  managers  a  tool  to  describe  how  system  growth 
could  affect  operational  mission  performance.  Has  this  tool  been  created,  and  what  is  its  efficacy 
in  predicting  MCS  mission  performance? 

In  the  final  analysis,  the  MCS  operations  simulator  created  during  this  research  provides 
results  comparable  to  the  MCS  in  terms  of  schedule  validity  and  operational  effectiveness.  It 
produced  an  valid  satellite  contact  schedule  for  the  full  24-satellite  constellation,  with  any  four 
of  the  five  Ground  Antennas  available  for  use,  With  three  GAs  available,  the  scheduler  failed  to 
schedule  at  most  four  of  2ty0  activities.  The  resulting  schedule  differed  from  the  MCS-generated 
schedule  due  to  its  use  of  a  subset  of  all  the  possible  MCS  activities  and  the  rudimentary  scheduling 
algorithm  used  in  the  <;imulation.  While  this  difference  precluded  direct  comparison  of  model 
results  to  MCS  output,  the  schedule  created  was  sufficiently  close  to  a  “real”  schedule  to  cause 
the  simulation  GA  utilization  results  to  match  the  known  response  of  the  MCS  to  GA  outages. 
With  additional  and  more  detailed  rules  for  defining  the  scheduling  process,  the  simulation  could 
schedule  even  closer  to  reality.  Of  course,  if  such  a  sophisticated,  rule-based  scheduler  was  created 
(one  that  that  produced  6c«er  schedules  than  the  MCS  schedulers),  the  human  element  could  be 
taken  "out-of-the-loop”  at  the  MCS  and  ihe  operational  and  simulated  schedules  would  be  identical. 
An  operational  simulation  under  these  conditions  could  predict  MCS  performance  very  accurately. 

The  MCS  simulator  created  here  has  other  useful  aspects.  The  behavior  of  the  scheduler 
WM  used  to  rate  the  relative  significance  of  a  number  of  MCS  failure  scenarios.  This  was  done 
by  assuming  the  human  scheduler  would  have  increased  difficulty  creating  a  schedule  under  the 
same  conditions  as  the  simulator.  Using  this  gauge,  the  various  combinations  of  GA  outages  were 
rated  by  impact  to  operations,  with  the  combination  of  a  KWAJ/DIEG  outage  being  the  most 
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significant.  Another  indication  was  that  a  DIEG  outage  was  more  difficult  to  schedule  than  some 
combinations  to  two  simultaneous  GA  outages.  GA  utilization  rates  produced  by  the  simulation 
were  explained  by  the  geographical  distribution  of  Ground  Antennas  and  the  effects  of  the  outages 
on  the  world-wide  coverage. 

With  few  changes,  this  model  could  be  adantcu  to  simulate  any  satellite  operational  environ¬ 
ment.  The  factors  that  make  the  model  uniquely  MCS-based  are  all  contained  in  data  files,  not 
coded  into  the  simulator  program.  In  fact,  with  slight  modification,  the  simulation  could  be  used 
to  model  any  operational  environment  that  is  driven  by  scheduled  events  with  fixed  time  windows. 

5.£  Recommendationa. 

The  simulation  as  it  stands  is  a  major  first  step  in  creating  a  usable  MCS  operations  simu¬ 
lation.  It  also  provides  clues  to  guide  the  creation  of  an  artificial  intelligence-based  scheduler  or 
scheduler’s  assistant.  The  following  list  describe  recommendations  for  improvement  of  the  MCS 
model  and  directions  of  further  research  in  this  subject. 

5.2.1  Add  Aciiviiiea.  Only  a  limited  number  of  MCS  activities  were  used  in  this  model, 
under  the  assumption  that  the  number  used  were  sufficient  to  test  model  performance  and  perform 
initial  experiments.  There  are  other  Icss-frequently  scheduled  activities,  related  to  satellite  eclipse 
operation,  for  instance,  that  need  to  be  added  to  improve  the  fidelity  of  the  model 

5.2.2  Extend  Environment.  The  MCS  can  operate  with  as  many  as  30  GPS  satellites  si¬ 
multaneously.  In  addition,  if  30  satellites  are  required  someday  and  the  present  ground  station 
network  proves  to  be  incapable  of  handling  the  load,  another  GA  might  need  to  be  added.  Experi¬ 
ments  could  be  run  to  test  this  hypothesis,  and  to  aid  in  determining  the  optimum  location  for  the 
additional  GA. 
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5.8.5  GA  SeltcUon.  The  simulation  currently  steps  through  the  list  of  GAs  in  fixed  order 
when  selecting  the  location  for  scheduling  an  activity.  The  next  order  of  embellishment  to  the 
scheduling  algorithm  should  include  a  smarter  method  for  selecting  GAs,  either  a  random  selection 
of  equally  valid  choices  or  more  rules  to  perform  the  selection  “smartly”. 

5. £.4  Operations.  There  was  insufficient  time  and  cause  to  experiment  the  stochastic  oper¬ 
ations  performance  model  written  into  the  simulation.  This  was  due  to  the  conservative  activity 
duration  times  associated  with  GPS  operations.  If  this  model  is  used  to  simulate  other  opera¬ 
tions,  or  research  into  the  effects  of  activity  durations  modeled  as  random  variables,  the  operations 
simulation  segment  is  there  for  that  use. 


Appendix  A.  MCS  Simulation  SIMSCRIPT  II.  5  Program  Listing 
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lOB  •'  identical  to  those  of  the  MASTER.. ACT.  except  for  the  dynamic 

106  '•  attributes  which  the  MASTER. ACT  entities  do  not  use. 

107  '* 

loe 

109  every  ACT  has 

110  a  IAMB, 

111  a  START. TIME. 

112  a  lEXT . START . TINE .  "  Tentative  start  of  new  activity 

113  a  LEAD. TINE. 

114  a  OURATIOI, 

11$  a  IITERVAL, 

116  a  IITERVAL . OFFSET .  ’*  Additional  Interval  time 

117  a  STATUS. 

118  a  SV, 

119  a  GA, 

120  a  GA.IRDBX, 

121  a  BLOCK. 

122  a  PRIORITY. 

123  a  VARIAICE. 

124  a  CRITICALITY 

128  and  may  belong  to 

126  the  TO. BE. SCHEDULED. 

127  the  SCHEDULED. 

128  the  PERFORMED. 

129  the  UI3CHSDULED 

130 

131  define 

132  START. TINE, 

133  lEXT. START. TINE. 

134  DURATIOI. 

136  IITERVAL. 

136  IITERVAL. OFFSET, 

137  PRIORITY. 

138  LEAD. TINS, 

139  VARIAICE. 

140  BLOCK, 

141  GA.IIDEX. 

142  CRITICALITY 

143  as  integer  variables 

144 

146  define 

146  lANE, 

147  STATUS, 

148  SV, 

149  GA 
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lEO  u  tszt  varlabl«8 
161 
162 

163  *’  Tha  VIS.BVIT  antitlaa  nalntain  the  calculated  riee  and  aet 

164  *'  tinea  oi  SV/GA  paira.  The  aource  of  the  data  ia  external  to 

166  ’*  thia  program. 

16« 

167 

168  every  VIS.EVBT  haa 

166  a  SV. 

leO  a  GA. 

161  a  GA.IHDBX, 

162  a  RISE. TIME,  ”  Riae  time  of  SV  at  GA 

163  a  SET. TIKE  "  Set  time  of  SV  at  GA 

164  and  may  belong  to 

166  the  VIS. TABLE 
166 

167  define 

168  RISE. TINE. 

166  SET. TINE 

170  aa  integer  variables 

171 

172  " 

173  “  The  folloving  connanda  specify  the  order  in  which  entities  are 

174  ”  maintained  in  the  various  system  queues.  The  rationale  for 

175  ’ ’  indicated  rankings  are  described  in  the  routines  where  the  queues 

176  ' '  are  naed. 

177  " 

178 

176  define 

180  TO. BE. SCHEDULED 

181  as  a  set  ranked  by 

182  high  PRIORITY ,  then  by 

183  low  IITERVAL 

184 
186 

186  define 

187  SCHEDULED 

188  as  a  set  ranked  by 

189  low  ST ART. TINE,  then  by 

160  low  SV 

161 

162  define 

163  PERFORHBD 

164  as  a  aet  ranked  by 

196  high  START. TIME,  then  by 

196  low  SV 

197 

198  define 

196  CHANGE. FLAG,  ’*  Indicates  an  exogenous  parameter  has  changed 

200  CURRENT. TINE.  "  Minutes  since  1  Jan  1992 
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201  EL. LIMIT,  ”  Elavatlon  throshold 

202  EIO.DAY,  ''  Dasired  ainulation  and  tima 

203  BID. HR.  *' 

204  BID. Mil,  *’ 

206  HUH.OF.GA,  "  luabar  ot  Ground  Antannaa  usad 

206  lUM.OF.SV,  "  luBbar  ol  Satallita  Vabiclas  used 

207  HUM.OF.OUTAGBS,  "  luabar  of  original  (schadulad)  GA  outogas 

208  ION . SINUL . COITACTS ,  "  Max  nuabar  of  siaultanaous  SV/GA  contacts  open 

200  SIM. BID. TIME,  “  Siaulation  coaplation  tiaa,  jainutas 

210  SIM. START. TINE,  "  Siaulation  start  tiaa,  jainutas 

211  START. DAY,  ”  Dasirad  siaulation  start  tiaa 

212  START.hr,  ’• 

213  START. Mil,  »’  " 

214  INBR. OFFSET,  "  Variablas  for  ACT  interval  offset  statistics 

216  MAX. OFFSET, 

216  NIH. OFFSET,  " 

217  OFFSET,  " 

218  IMBR.PRI,  "  Variablas  for  ACT  priority  statistics 

219  MAX.PRI,  " 

220  MII.PRI, 

221  PRI,  ’* 

222  INBR. UTIL,  "  Variablas  for  GA  utilization  statistics 

223  MAX.  UTIL,  "  " 

224  Mil. UTIL, 

226  UTIL,  ” 

226  INBR. START. OFFSET,  ''  Variablas  for  validation  offset  statistics 

227  MAX. START. OFFSET.  ” 

228  Mil. START. OFFSET,  " 

229  ST ART. OFFSET,  ’* 

230  RESV,  * ‘  Variablas  for  GA  reservation  statistics 

231  MAX . PRIORITY ,  '*  Maxinom  ACT  priority 

232  IITBRVAL . OFFSET . STEP ,  "  Value  of  interval  offset  increase 

233  FAILED,  "  lumbar  of  failed  supports 

234  ASCI. UTIL,  ’’  Variablas  for  individual  GA  statistics 

236  CAPE. UTIL,  " 

236  DIEG.UTIL, 

237  KMAJ.UTIL, 

238  PIKE.  UTIL,  "  " 

239  ASCI. RESV, 

240  CAPE. RESV, 

241  DIBG.RESV, 

242  KWAJ.RESV, 

243  PIKE. RESV 

244  as  integer  wiables 

245 

246  define 

247  REMARK 1 . 

248  REMARK2 , 

249  REMARKS , 

260  VIS. FILE, 

261  TIME. FILE, 


Text  description  of  experiment,  parauaeters,  etc. 
''  Text  description  of  experiment,  parameters,  etc. 
''  Text  description  of  experiment,  parameters,  etc. 
”  Pointer  to  file  containing  visibility  data 
’’  Pointer  to  file  containing  sim  parameter  data 
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262  OUTAGE. FILE.  ”  Pointer  to  lile  coat&lning  GA  outage  data 

263  ACT. FILE,  *'  Pointer  to  file  containing  initial  activity  data 

264  OUT. FILE,  '•  Pointer  to  file  to  contain  siiii  results 

266  VAL.OUT  “  Pointer  to  file  to  contain  validation  results 

256  as  text  variables 

267 

288  ' ' 

269  ”  The  GA. USAGE  arrays  aaintains  the  GA  utilization  data  for  each 

260  "  GA  for  each  minute  of  the  simulation. 

261  " 

262 

263  daf ine 

'64  GA. USAGE 

2b'  as  a  2-dim  text  array 

13' 

J  v7  '  * 

268  ' ’  The  following  TALLY  statements  invoke  autonomous  system  monitoring 

260  * ‘  of  the  variables  named  in  the  last  line .  Each  time  the  variables 

270  *'  change,  the  nes  value  is  automatically  noted  and  the  listed 

271  '*  statistics  recalculated. 

272  •’ 

273 

274  tally 

276  Ml. OFFSET  as  the  mean, 

276  STD. OFFSET  as  the  std.dev, 

277  INBR. OFFSET  as  the  number, 

278  MAX. OFFSET  as  the  maximum . 

279  Nil. OFFSET  as  the  minisram, 

280  HIST.OFFSETCO  to  240  by  10)  as  the  histogram 

281  of  OFFSET 

282 

283  tally 

284  INBR. UTIL  as  the  number. 

286  Ml. UTIL  as  the  mean. 

286  STD. UTIL  as  the  std.dev. 

287  MAX. UTIL  as  the  maximum, 

288  Nil. UTIL  as  the  minimum, 

289  8IST.UTIL(0  to  6  by  1)  as  the  histogram 

290  of  UTIL 
201 

292  tally 

293  INBR.RESV  as  the  number, 

294  Ml.RESV  as  the  mean, 

296  STD.RESV  as  the  std.dev, 

296  NAX.RESV  as  the  maximum, 

297  NII.RESV  as  the  minimum, 

298  HIST.RESVCO  to  6  by  1)  as  the  histogram 

209  of  RESV 

300 

301  tally 

302  IMBR.PRI  as  the  n'jmber. 


A-6 


303  Nl.PRI  as  tha  Bsaii, 

304  STD.PRI  as  the  std.dev, 

305  NAX.PRI  as  the  maximuM, 

306  MII.PRI  as  the  nlnlmum, 

307  HIST.PRKO  to  11  by  1)  as  the  histogram 

308  ot  PRI 

309 

310  tally 

311  INBR. START. OFFSET  as  the  number. 

312  n . START . OFFSET  as  the  mean, 

313  STD . START . OFFSET  as  the  std.dev, 

314  MAX . START . OFFSET  as  the  maximum, 

315  Mil. START. OFFSET  as  the  minimum. 

316  BIST. SO (0  to  200  by  10)  as  the  histogram 
3.7  ol  START. OFFSET 

318 

319  tally 

320  MR.AUTIL  as  the  mean. 

321  STD.AUTIL  as  the  std.dev 

322  of  ASCI. UTIL 

323 

324  tally 

325  KI.CUTIL  as  the  mean, 

326  STD.CUTIL  i.e  the  std.dev 

327  of  CAPE. UTIL 

328 

329  tally 

330  MI.DUTIL  as  the  mean, 

331  STD.DUTIL  as  the  std.dev 

332  of  DIEG.UTIL 

333 

334  tally 

335  Nl.KUTIL  as  the  mean, 

336  STD.KUTIL  as  the  std.dev 

337  of  KWAJ.UTIL 

338 

339  tally 

340  MI.PUTIL  as  the  mean, 

341  STD.PUTIL  as  the  std.dev 

342  c  PIKE. UTIL 

343 

344  tally 

345  NI.ARESV  as  the  mean, 

346  STD.ARESV  as  the  std.dev 

347  f  ASCI.RESV 

348 

349  tally 

350  NI.CRESV  as  the  mean, 

351  STD.CRESV  as  tha  std.dev 

352  of  CAPE.RESV 

353 
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364  tally 

366  NI.DRBSV  as  the  mean, 

360  STD.DRESV  as  the  std.dev 

367  of  DIEG.RBSV 

368 

360  tally 

360  KI.KRESV  aa  the  mean, 

301  STD.KRESV  as  the  std.dev 

362  of  KVAJ.RESV 

303 

364  tally 

366  KI.PRESV  as  the  mean, 

366  STD.PRESV  as  the  std.dev 

367  of  PIKE.RESV 

368 

360  end  * ' the  preamble 
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A.2  MAIN 


370 

371  *  >*4i*««**««««*«*«*4i««***4i******«««****«««****4i4i 

372  '  >*t^*i^**i¥*  H*********************4**********ir*** 

373  ’ ’***********^^****^******************0*******’* 

374 

37  B  Bain 

376 

377  ’ ' 

378  ' '  The  Mill  prograat  aegment  control  the  flow  of  the  program  by 

376  ' ’  defining  the  execu'  ion  sequence  of  the  program  routines  and 

380  processes. 

881  " 

382  "  The  first  four  routines  initialize  the  simulation  and  are  only 

383  ' '  executed  once  at  the  start  of  the  simulation 

384  " 

386 

-*66  now  R2iD  DATA 
7  row  READ. VIS 
w8  now  HIT. QA. USE 
386  now  HIT. ACTS 

360 

361  ’  ’ 

362  "  The  PRESCHEOUI.E  routine  kicks  off  the  scheduling  sequence.  It 

363  *’  will  be  called  anytime  a  new  schedule  is  required. 

364  " 

366 

366  now  PRESCHEOULE 

367 

368  '• 

366  "  The  START. OPS  process  is  the  first  step  in  the  operations 

400  "  simulation  process,  which  starts  after  the  initial  schedule  has 

401  *'  been  calculated. 

402  ’* 

403 

404  schedule  a  START. OPS  now 
406  start  simulation 

406 

407  " 

408  ' '  The  remainder  of  the  routines  called  by  MAIN  describe  the  state 

406  '*  of  the  simulation  after  the  simulation  has  completed,  and 

410  ”  statistics  pertaining  to  critical  performance  measures. 

411  " 

412 

413  now  REPORT. USE 

414  now  REPORT . QUEUES 

415  now  ARAUSIS 

416  now  VALIDATE 

417  stop 

418 

416  end* ’main 
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A.S  READ. DATA  Routine 

420 

-421  ' ********************************************* 

422  ' '**************************•****•****»***•*** 

*2o  ■  '^******************«********t*************** 

424 

425  routine  READ. DATA 

426 

427  >' 

428  ' ’  This  routine  "bootetraps"  the  renainder  of  the  initialization 

420  ’*  sequence.  It  reads  data  from  the  system  default  data  file,  which 

430  ”  sots  the  basic  simulation  parameters  and  points  to  the  subsequent 

431  "  input  data  files.  This  "indirect"  input  method  allows  all 

432  “  simulation  parameters  to  be  changed  by  modifying  the  default  data 

433  '•  file  only. 

434  " 

436 

436  ’ 

437  "  Where  are  the  other  data  files? 

438  •’ 

439 

440  read 

441  VIS. FILE, 

442  TIME.  FILE. 

443  OUTAOE.FILE, 

444  ACT. FILE, 

446  OUT. FILE, 

446  VAL.OUT 

447 

448  " 

449  ”  These  variables  allow  the  user  to  describe  .he  simulation  run. 

460  ”  They  are  later  Included  with  the  output  files  to  "stamp"  the 

461  "  simulation  operating  conditions  on  the  output. 

462  ' ' 

463 

464  read 
466  REMARXl, 

466  REMARKS, 

467  REMARKS 

468  as  3  T  * 

469 

460  open  unit  2  for  inj  name  is  TINE. FILE 

461  use  unit  2  for  input 

462 

463  " 

464  ’*  .lead  the  simulatiuii  time  period  desired. 

465  ’  ’ 

468 

467  read 

468  START. DAY, 

469  START.hr, 


470  START.  MU, 

471  EIO.DAY, 

472  BID.  HR, 

473  BID.  Mil 

474 

475  " 

476  ”  Convart  tha  daalrad  tima  linlta  to  ''j<ninutes" . 

477  ’* 

478 

479  lat  SIN. START. TIME  s  START. DAY* 1440  * 

480  START. HRaSO  ^ 

491  START.  MU 

482  let  SIN. BID. TIME  »  BID. DAY* 1440  > 

483  BID.HRaeO 

484  BID. Nil 

486  lat  CURRBIT.TIME  =  SIM. START. TIME 

486 

487  ’* 

488  "  Read  the  nuabar  of  sinultanaous  contacts  alloaad,  tha  Daxinuio 

489  "  activity  priority,  and  tha  initial  intarval  offset  incranantation 

490  ' '  value . 

491  ’• 

492 

493  read 

494  lUM.SIMUL.COITACTS, 

496  MAX. PRIORITY, 

496  IITERVAL.  OFFSET.  STEP 

497 

498  close  unit  2 

499 

600  " 

601  "  The  operations  simulations  process  uses  resources  to  heap  track 

602  ”  of  GA  utilization.  These  resources  are  created  nov. 

603  " 

604 

606  create  evory  COITACT(l) 

606  let  u.COITACTU)  =  IDN.SINUL.COITACTS 

607 

508  end' 'READ. DATA 


All 
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609 
810 
611 
612 

613 

614 
616 
616 

617 

618 

610 
620 
621 
622 

623 

624 
626 
626 

627 

628 
626 

630 

631 

632 

633 

634 
636 

636 

637 

638 
630 

640 

641 

642 

643 

644 
646 

646 

647 

648 

649 
660 
661 
662 

663 

664 
666 
666 

667 

668 


READ.  VIS  houtine 


>  >  ***************** ******* ******************** 


routine  READ. VIS 


I  > 

'  *  This  routine  is  used  to  read  the  externally  prepared  visibility  record. 
’ '  The  data  aust  be  synchronized  with  the  simulation  time  period  and  the 
'  ’  preliminary  activity  data.  The  visibility  data  is  then  used  to 
••  initialize  VIS.BVIT  entities  and  the  VIS. TABLE  set. 

f  I 


define 


.i,  ”  Counter 


. j ,  '  ’  Counter 


.EUN.OF.EVITS 

.RDAY, 

.RHOUR. 

.RNII. 

.SDAY, 

.SHOUR. 

.SNIR, 
.OA.IIDEX. 
.JDAY. OFFSET 


,  ' ’  The  number  of  visibility  periods  to  be  read 
' ’  The  day  of  the  month  the  SV  rises  at  GA 
’ '  The  hour  of  the  month  the  SV  rises  at  GA 
' '  The  minute  of  the  month  the  SV  rises  at  GA 
"  The  day  of  the  month  the  SV  sets  at  GA 
' '  The  hour  of  the  month  the  SV  sets  at  GA 
' '  The  minute  of  the  month  the  SV  sets  at  GA 
"  The  numerical  "tag"  for  this  GA 
* '  The  number  of  days  from  1  Jan  to  the  1st  of 


the  month  of  the  simulation 


as  integer  variables 


define 

.SV,  ' '  ‘  SV  text  name 
.GA  ”  The  GA  text  name 
as  text  variables 


open  unit  2  for  input,  name  is  vis. FILE 
use  unit  2  for  input 


f  t 

’’  First,  the  number  of  Ground  Antennas  used  in  tho  ^  .ulation  is  read, 
’’  then  the  days  from  1  Jan  to  the  start  of  the  n  '.ne  ’imulation 
”  begins.  Rote  that  for  simplicity,  the  simul  unot  ’trap" 

' '  around  a  month  boundry . 

t  I 

I  I 

Here  is  a  sample  of  the  data  format  for  the  visibility  data  file, 

'*  for  reference. 

i  I 

"  690  "lUM. OF. GA, .JDAY, OFFSET" 

"  ASCI  1  ".GA, .GA.IIDEX" 
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".SV. .ROAY. .REOUR, .RHIl, .SHOUR, .SHII 


660 

"  BII-26  9  18 

39 

1 

11 

660 

>  » 

661 

"  BII-06  14  23 

4 

6 

42 

662 

>  >  BID  0  0  0  0  0 

663 

"  CAPE  2 

664 

"  BII-04  9  18 

17 

1 

0 

666 

666 

■  •  BI-OIO  14  23 

66 

4 

60 

667 

' »  EIU  0  0  0  0  0 

668 

1  > 

669 

670 

read 

671 

Kim.OF.GA. 

672 

.JDAY. OFFSET 

673 

674 

for  .1  =  1  to  lUM.OF.GA 

do 

676 

676 

read 

677 

.CA. 

678 

.CA.IIDBX 

679 

680 

let  .SV  =  "" 

681 

until  .SV  *  "BID" 

do 

682 

683 

read 

684 

.SV. 

686 

RDAY, 

686 

.RHOUR, 

687 

.RNII, 

688 

.SHOUR, 

680 

.SNII 

600 

691  il  .SV  ne  "EID" 

602 

693  cr«at«  a  VIS.BVIT 

694 
606  ” 

606  ' ’  Nak«  a  corraction  to  th«  act  day  if  the  event  overlaps 
697  "  OOOOhra. 

608  " 

699 

600  if  .RBOUa  <=  .SHOUR 

601  let  .SDAY  »  .RDAY 

602  else 

603  let  .SDAY  =  .RDAY  +  1 

604  endif 
606 

606  " 

607  "  Calculate  the  number  of  minutoa  from  0000  1  Jan  (called 

608  "  jainutes). 

609  " 
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610 

611  Iflt  RISE  TIIIE(VIS.BVIT)  -  1440«(.mY  *  .JDAY. OFFSET)  * 

612  60*.IlH001l  + 

613  .RMII 

614  l*t  SBT.TIMB(VIS.BVIT)  =  1440* (.SOAY  ♦  .JDAY. OFFSET)  + 

616  60*. SHOOK  + 

616  .SKII 

617  l*t  GA(VIS.EVIT)  *  .GA 

618  l«t  GA.IIDEX(VIS.F.V>T)  «  .GA.IIOEX 

619  l#t  SV(VIS.BVIT)  =  .SV 

620 
€21  •’ 

622  "  Once  tha  entity  has  its  attributes  eet,  it  is  tiled  in 

623  "  tbe  VIS. TABLE  queue  by  los  START. TINE,  uhich  aaounte  to 

624  ’ '  chronological  order . 

626  " 

626 

627  tile  this  VIS.BVIT  in  VIS. TABLE 

628 

629  endlt 

630  loop 

631  loop 

632 

633  close  unit  2 

634 

636  end  * 'routine  READ. VIS 
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A.S  INIT. GA .  USE  Routine 


636 

637 

938  *  »*•*•****•**•••••••*••••••••••••••*•*••*•****• 

639  * 

640 

641  rontin*  HIT. GA. USB 

642 

643  " 

644  ’’  Thia  routlna  rvada  in  an  initial  ground  antenna  uaa  achedule.  The 

646  "  nae  could  be  froa  preacheduled  contacta,  achedulad  GA  maintenance, 

646  ’’  NCS  acheduled  aAlntenance  or  testing,  or,  in  the  case  of  validation, 

647  ' *  unscheduled  outages  that  occured  during  the  validation  period.  An 

646  ’ '  array  ia  used  to  reduce  storage  requirementa  and  improved  processing 

640  *'  time. 

660  " 

661 

662  define 
653  .GA, 

664  .GA.IIDEX, 

666  .START. TIKE, 

666  .DURATIOI, 

667  .i, 

666  .j, 

660  . OFFSET  ' *  Used  to  translate  jninutea  to  array  index 

660  as  integer  variables 

661 

662  define 

663  .CAUSE  "  The  reason  for  the  outage. 

664  as  a  text  variable 
666 

666 

667  reserve 

668  GA.USA0B(*,«} 

660  as  6  by  (SIK. BID. TIKE  -  SIH. START. TIME  1} 

670 

671  open  unit  2  for  input,  name  ia  OUT  AGE.  FILE 

672  use  unit  2  for  input 

673 

674  " 

676  "  A  sample  outage  file  is  shovn  below: 

676  " 

677  *'  "ASCI  out  lor  entire  simulation."  "REMARKl" 

678  "  "DIEG  out  for  entire  simulation."  "REMARK2" 

679  "  2  "lUK. OF. OUTAGES" 

680  *’  1  144000  2880  OUTAGE  ".GA.IIDEX, .START. TIME, .DURATIOI,  .CAUSE" 

681  "  3  144000  2880  OUTAGE 

632  " 

683 

684  road 

686  REMARKl, 
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686  RBMiRK2 

687  M  2  T  * 

688 

689  r««d  lUN.OF.QUTAQBS 
660 

661  if  lUH. OF. OUTAGES  >  0 

662 

663  for  .QA  s  1  to  lUM . OF . OUTAGES  do 

664 

666  rood 

696  .aA.IIDBX, 

697  .STAET.TINE. 

698  .DURATIOI. 

696  .CAUSE 

700  lot  .OFFSET  *  .START. TIMS  -  SIM . START . TIME 

701  for  .1  B  .OFFSET  to  .OFFSET  *  .DURATIOI  do 

702  lot  6A.USAGE(.GA.IIDBX.  .i^-l)  =  .CAUSE 

703  loop 

704  loop 
706 

706  ondif 

707 

708  cloio  unit  2 

709 

710  * ' 

711  "  Tlio  follooin|(  routino  roplocoa  tbo  dofaolt  vaulos  for  tho 

712  "  6A. USAGE  array  (a  noil  otriog)  vith  10  opacot.  Thit  iaprovoo 

713  "  tho  appoaranco  of  tho  array  vhon  output. 

714  " 

716 

716  for  .1  B  1  to  6  do 

717  for  .J  e  0  to  SIM. EIO. TIME  -  SIM. START. TIME  do 

718  if  GA.USA0B(.i.  .j+l)  »  "" 

719  lot  GA.USA0E(.i,  .j+l)  *  " 

720  ondif 

721  loop 

722  loop 

723 

724  oad  "routino  HIT. GA. USE 
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A.€  INIT. ACTS  Routine 
726 

726  > • ***♦♦*♦#*♦•*♦♦***♦•••****•••*••••*••***••*•* 

727  * 

728  "•*♦*♦•****♦•♦*♦*♦♦♦•♦*•♦***••**•♦*♦•♦**•♦*♦♦ 

720 

730  rout  in*  HIT.  ACTS 

731 

732  " 

733  **  This  routlns  Inltlalizas  tha  ACT  antitias  naadad  to  "hotstart"  tha 

734  '*  •iBUlatlon.  Thay  providaa  tha  nacaasary  contact  history  (prior  to 

73E  "  tha  start  of  tha  ainulation)  so  tha  priority  of  tha  contacts  can  ba 

736  "  calcalatad. 

737  '* 

738 

739  daf ina 

740  .SV. 

741  .BLOCK, 

742  .ST  ART.  TIKE, 

743  .DORATIOI, 

744  .IRTBRVAL, 

745  .PRIORITY, 

746  .VARIAICB, 

747  .CRITICALITY, 

746  .run. OP. ACTS 

749  as  intagar  variablas 

760 

761  daf Ina 

762  .SV.IAMB, 

763  .ACT.IAIIE 

764  as  tart  vaxiablas 
766 

766  opaa  unit  2  for  input,  naaa  is  ACT. FILE 

767  usa  unit  2  for  input 
7S8 

769  " 

760  ' '  Bara  Is  a  saapla  ACT . FILE ; 

761  *’ 

762  ”  16  "nm.OF.SV" 


763  '  ’ 

61 

".lOM.OF.ACTS" 

764  ” 

BI-008 

1  ADDKEYS  143816 

10 

1 

1 

4320 

766  " 

BI-008 

1  lAV 

143232 

6 

1 

1 

1440 

766  " 

BI-008 

1  SOB 

143806 

10 

1 

1 

480 

767  " 

768  ”  ".SV.IAHE,  .BLOCK,  .ACT. I ABE,  .START. TIME,  .DURATIOH, 

769  "  .VARIAICE,  .CRITICALITY,  .IITERVAL" 

770  ” 

771  raad 

772  rm.OF.sv, 

773  .BUM. OF. ACTS 

774 
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776  CTMt*  6T«Tr  MASTER. ACK.IUM. OF. ACTS) 

776 

777  for  ovary  MASTER. ACT  do 

778 

779  road 

780  .SV.IANE,  I 

781  .BLOCK,  j 

782  .ACT. IAMB.  1 

783  .START. TINE, 

784  .DURATIOI, 

786  .VARIAICB, 

786  .CRITICALITY, 

787  . IITERVAL 

788 

789  lot  NSV(NASTBR.ACT)  =  .SV.IANE 

790  lot  NBLOCK(NASTER.ACT)  =  .BLOCK 

791  lot  MSTATUS(MASTER.Aa)  =  “UISCBD" 

792  lot  NIAME(NASTER.ACT)  =  .ACT. IAMB 

793  lot  KSTART.TIME(MASTER.ACT)  =  .START. TIME 

794  lot  MDURATIQI(MASTBR.Aa)  =  .DURATION 

796  lot  MIITBRVAL(NASTBR.ACT)  -  .IITERVAL 

796  lot  MCRITICALITY(MASTER.ACT)  =  .CRITICALITY 

797  lot  MVARIAICB(NASTBR.ACT)  -  .VARIAICE 

798 

799  '' 

800  ••  Tho  ordorlnf  of  tho  MASTER. ACT  ontitios  in  MASTER  is  not 

801  "  iiiportant. 

802  *» 

803 

804  filo  this  MASTER. ACT  in  MASTER 
806 

806  croato  an  ACT 

807 

808  lot  SV(Aa)  >  NSV(NASTBR.ACT> 

809  lot  BLOCKCACT)  =  NBLOCKC MASTER.  ACT) 

810  lot  STATUS (ACT)  MSTATUS (MASTER. ACT) 

811  lot  lAMB(ACT)  -  NIANB(NASTER. ACT) 

812  lot  LBAO.TIHB(ACT)  -  NLEAO.TIHE(NASTBR.ACT) 

813  lot  START. TINB( ACT)  -  MSTART.TINE(MASTER. ACT) 

814  lot  DURATIOI(ACT)  <  MDURATIOI (MASTER. ACT) 

816  lot  IITERVAL(ACT)  s  MIITBRVAL(NASTER. ACT) 

816  lot  CRITICALITY(ACT)  *  MCBIT:CALITY(MASTER. ACT) 

817  lot  VARIAICE(ACT)  =  MVARIARCE(HASTER. ACT) 

818 

819 

820  "  Tho  ordoring  of  tho  ACT  ontitioo  in  PERFORMED  is  by  high 

821  "  START. TIME,  so  that  vhon  tho  quouo  is  soazchod  tho  latest 

822  "  oxanplo  of  oach  typo  of  ontity  is  found  first. 

623  " 

824 

826  filo  this  ACT  in  PERFORMED 
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B2e 

827  loop 

828 

820  cloB«  unit  2 

830 

831  •ud"  rout  in*  HIT.  ACT* 
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A.l  MAKE.NEW.ACT  Routine 

832 

833  *  *•♦♦•••*♦♦**•♦**••*•*♦♦♦♦•****•♦*♦♦***♦*••••* 

834  ' 

836 

836 

837  routine  NAXE.IEW. ACT  given  .ACT  yielding  .IBM. ACT 
836 

839  ' ' 

840  ' '  This  routine  slaply  takes  the  ACT  entity  shoes  pointer  it  is 

841  *’  passed  and  duplicates  it,  creating  a  nes  entity  with  the  sane 

842  '*  attribute  values.  The  pointer  ot  the  nes  entity  is  then 

843  *'  passed  back  to  the  calling  routine. 

844  ' ' 

846 

846  del ine 

847  .lEU.ACT. 

848  . ACT 

849  as  pointer  variables 
860 

861  create  an  ACT  called  .lEU.ACT 

862 

863  let  IAMB(. lEU.ACT)  =  lAME(.ACT) 

864  let  SV(. lEU.ACT)  =  SV(.ACT) 

866  let  BL0CK(. lEU.ACT)  =  BLOCK(.ACT) 

866  let  START.  TIKE  (.lEU.ACT)  =  START.  TIME(  .ACT) 

867  let  IBXT. START. TIKB(. lEU.ACT)  =  IBXT. START. TIKE (.ACT) 

868  let  OURATIOK.  lEU.ACT)  =  DURATIQK  .  ACT) 

869  let  IITERVAL(. lEU.ACT)  =  IITERVAL( . ACT) 

860  let  IITBRVAL.OFFSET(.  lEU.ACT)  =  I ITERVAL.  OFFSET  (.ACT) 

861  let  VARIAICB(. lEU.ACT)  -  VARIAICE( . ACT) 

862  let  CRITICALITY (.lEU.ACT)  =  CRITICALITY( . ACT) 

863  let  STATUS (.lEU.ACT)  =  STATUS(.ACT) 

864  let  PRI0BITY(. lEU.ACT)  =  PRI0RITY( . ACT) 

866  let  GA(. lEU.ACT)  =  GA(.ACT) 

866  let  GA.II0BX(. lEU.ACT)  =  GA.IIDEX( . ACT) 

867 

868  end"  routine  MAKE. UEU. ACT 
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A.8  PRESCHEDULE  Routine 


869 

870  • •***♦**♦♦*♦♦*♦♦****•**♦♦*•♦♦•♦*♦♦****•*♦•♦♦♦♦ 

871  >  i^^^t^Lttmii*********************************** 

872  ’ >******************************************** 

873 

874  routine  PRBSCHBOULE 
876 

876  " 

877  ’•  FOICTIOI; 

878  ' *  -  Create  one  ACT  lor  each  SV  activity  that  needs  to  be  performed 

879  "  at  least  once  more  prior  to  the  end  of  the  simulation,  and  place 

880  "  this  ACT  in  TO . BE . SCRBOULEO  if  there  isn't  one  corresponding 

881  ’*  to  that  activity  in  TO. BE  SCHEDULED  already. 

882  " 

883  "  liPUT  COIDITIOIS: 

884  ’*  -  One  MASTER. ACT  entity  filed  in  MASTER  lor  each  routinely 

885  *'  required  SV  activity  for  each  SV. 

886  " 

887  "  -  One  ACT  entity  filed  in  PERFORMED  as  above,  with  START. TIME( ACT) 

888  “  indicating  the  last  time  this  activity  was  performed  prior 

889  "  to  the  simulation  start  time. 

890 

891 

892  del  me 

893  .IBV.ACT 

894  as  pointer  variables 
896 

896  print  1  line  thus 
PRBSCEEDULE 

898 

899  " 

900  '*  Iterate  through  the  list  of  activities,  taking  each  ACT 

901  "  one  at  a  time. 

902  ' ' 

903 

904  for  every  MASTER. ACT  in  MASTER  do 
906 

906  *» 

907  "  Find  the  latest  occurrance  of  the  specific  ACT  in  the 

908  ' '  PERFORMED  queue . 

909 

910 

911  for  every  ACT  i.'i  PERFOPMEl' 

912  with  SV(ACT)  =  ^fOV (MASTER. ACT)  and 

913  lAME(ACT)  -  MaA!!S(?!ASTER.  ACT) 

914  find  the  rirst  case 

916  if  found 

916 

917  '  ' 

918  ' '  This  ACT  need  onlt  be  considered  for  further  performance  if 
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S19  ' '  it  can  ba  coaplatad  prior  to  tha  and  ol  tha  simulation 

920  ' ' 

921 

922  il  STiRT.TIKB(ACT)  + 

023  IRTBRVAL(ACT) 

024  IITERVAL.OFFSBT(ACT)  + 

02B  DURATIOI(ACT)  <  SIH.EMD.TIKE 
026 
027  '• 

028  "  Thia  ACT  meata  all  tha  critaria  lor  baing  achaduled  again. 

020  "  Haka  a  copy,  changa  tha  atatus  to  “UNSCBD'*,  and  lils  it  in 
030  ”  TO . BB . SCBBOULED .  In  addition,  triggar  tha  collection  ol 
031  *’  tha  parlonianca  atatiatica  on  thia  entity. 

032  " 

033 

034  nov  HAKE. IBU. ACT  giving  ACT  yielding  .MEV.ACT 
036  let  STATUS (.lEM. ACT)  =  "UISCHD" 

036  let  LEAD. TINEC.IEW. ACT)  =  START. TIME( .HEW. ACT)  * 

037  IITBRVAL(.IEU.ACT)  - 

938  CURREHT.TINE 

939  let  OFFSET  =  IITERVAL.OITSET(ACT) 

940  let  PRI  =  PRIORITY(ACT) 

941  let  PRIORITY(.HEW.ACT)  =  0 

942  let  IITERVAL. OFFSET (.HEW. ACT)  =  0 
043  Xile  thia  .HEW. ACT  in  TO . BE . SCBEOULEO 

944 

945  endil 
046  endil 
047  loop 

048 

949  ' » 

960  ''  Do  not  call  the  scheduler  if  there  zure  no  activitiaa  to  be  scheduled. 

961  ' '  Thia  routine  falls  through  to  tha  start  of  the  simulation  if  the 

962  achedula  is  completed.  The  tentatively  scheduled  activities  eura 

963  ''  promoted  to  the  SCHEDULED  queue  and  tha  others  are  destroyed. 

964  ' ' 

066 

966  if  TO . BE . SCHEDULED  is  empty 

967 

968  for  every  ACT  in  PERFORMED  do 

969  if  STATUS (ACT)  =  "TEIT" 

960 

961  let  STATUSCACT)  =  "SCHD" 

962  remove  this  ACT  from  PERFORMED 

963  file  this  ACT  in  SCHEDULED 

964 

066  else 

066 

067  remove  thia  ACT  from  PERFORMED 

968  destroy  this  ACT 

909 
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670  endif 
071  loop 

972 

973  also 

974 

976  noa  SCHEDULE 

976 

977  andil 

978 

979  and  ’’PRESCHEDULE 
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A.9  SCHEDULE  Routine 


980 

981 

982  ’ >**if***************************************** 

983  ’  <»*4i*«**«**«**#4i4i4r«**#*«***«**«*«*«*«*«*i»««** 

984  '  '***«4i****«4i****««*********«*«#*««*««*4i4i4i**** 

98B 

986  routine  SCHEDULE 

987 

988  " 

989  "  This  routine  takes  all  the  activity  entities  in  the  TO . BE . SCHEDULED 

990  ’*  queue  and  iteratively  tries  to  find  suitable  time  periods  in  the 

991  "  schedule  for  them  to  be  performed.  If  it  succeeds,  it  calls 

902  ”  PRBSCHEDULE  to  determine  if  there  are  further  activities  required. 

993  ’ '  If  it  cannot  schedule  one  or  more  activities  due  to  resource 

994  '*  it  "forgets"  shat  it  has  done  to  that  point  and  restarts  itself, 

996  "  except  that  the  troublesome  activities  have  been  modified  to  improve 

996  the  probability  they  sill  be  scheduled.  If  it  exhausts  all 

997  •'  possibility  of  scheduling  an  activity,  the  routine  marks  the 

998  "  activity  as  hopeless  and  henceforth  ignores  it. 

999 

1000  define 

1001  .CICT. START,  ’’  Tentative  start  time  currently  under  test 

1002  .COIFLICT,  ''  Flag  indicating  a  scheduling  conflict  occurred 

1003  .T,  "  Counter  (in  minutes) 

1004  .i,  "  General  purpose  counter 

1006  .I.COITACTS,  ’’  lumber  of  contacts  currently  scheduled 

1006  .OFFSET,  ’’  Naps  from  sim  time  to  GA. USAGE  index 

1007  .START. TINE,  ’’  Temporary  storage  for  START. TIME  calculations 

1008  .GA, 

1009  .CUT. OFF,  ’’  Earliest  search  time 

1010  . RESCBD . FLAG ,  ’’  Set  if  reschedule  is  required 

1011  .PRIORITY. STEP  ''  Current  priority  step  value 

1012  as  integer  variables 

1013 

1014  define 

1016  .USE  ”  temp  storage  for  current  GA. USAGE  value 

1016  as  a  text  variable 

1017 

1018  define 

1019  .lEW.ACT 

1020  as  a  pointer  variable 

1021 

1022  lot  .RESCHD.FLAG  =  0 

1023  let  .PRIORITY. STEP  =  1 

1024 

1026  for  every  ACT  in  TO. BE. SCHEDULED 

1026  with  STATUSCACT)  =  "UBSCHD" 

1027  while  STATUS (ACT)  =  "UBSCHD"  do 

1028 

1029  remove  this  ACT  from  TO. BE. SCHEDULED 
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1030  l«t  . CUT. OFF  =  mwt.f (START. TIME(ACT) ,  CURREIT. TIME) 

1031 

1032  lor  .CICT. START  back  Irom  START. T1ME< ACT)  + 

1033  irraRVAL(ACT)  ♦ 

1034  IITERVAL.OFFSET(ACT)  to  .CUT. OFF 
1038  with  . CICT. START  <=  SIM. BID. TIME 

1036  whilo  STATUS(ACT)  =  "UISCHD"  do 

1037 

1038 

1036  '*  Stop  thru  the  visibility  periods  of  the  SV  that’s  being 

1040  ’’  scheduled  at  any  (and  all)  GAs,  provided  the  period  ol 

1041  ' '  visibility  is  longer  them  the  length  ol  the  desired  contact 

1042  ' ' 

1043 

1044  lor  every  VIS.EVRT  in  VIS. TABLE 

1046  with  SV(VIS.EV«T)  =  SV(ACT)  and 

1046  RISE. TIME( VIS. EVBT)  <=  .CBCT. START  and 

1047  SET.TIME(VIS.EVIT)  >=  .CICT. START  +  DURATIOH(ACT) 

1048  while  STATUS(ACT)  =  "UiSCHD"  do 

1049 
1060  ” 

1061  "  Assume  this  prospective  contact  Bill  not  conllict 

1062  '  ’  with  another  GA  use 

1063  ” 

1064 

1066  1st  .COBPLICT  =  0 
1066 

1067  ” 

1068  ’’  Step  through  the  minutes  ol  the  prospective  contact, 

1069  ”  checking  lor  correspondence  in  the  GA  use  set. 

1060  "  II  there  is,  set  the  conllict  llag. 

1041  ” 

1062 

1063  lor  .t  2  0  to  DURATIOI(ACT) 

1064  while  .COIFLICT  ne  1  do 
1086 

1066  let  .OFFSET  =  (.CICT. START  +  .t  +  1)  -  SIM. START. TIME 

1067  il  GA.USAGE(GA.IIDEX(VIS.EVIT),  .OFFSET)  ne  " 

1068 

1069  let  .COIFLICT  =  1 

1070 

1071  endil 

1072 

1073  let  .I.COITACTS  =  0 

1074  lor  .GA  =  1  to  6 

1076  with  .GA  ne  GA.IIDEX(VIS.EVIIT) 

1076  while  .COWFLICT  ne  1  do 

1077 

1078  il  substr.l(GA.USAGE(.GA, .OFFSET) ,1,6)  =  SV(ACT) 

1079  let  .COIFLICT  *  1 

1080  endil 


1081 

1U82  l«t  .USB  -  G A. USAGE (.G A ..OFFSET) 

1083  11  substr.K.USE.l.l)  =  "B" 

1084  add  1  to  .1.  comers 

1086  endll 
1086 

1087  loop"  n«xt  .GA 

1088 

1089  il  .I.COITACTS  >=  RUM.SIMUL.COBTACTS 

1090  lot  .COKFLICT  =  1 

1091  endll 

1092 

1093  loop"  next  .t 

1094 
1096  " 

1096  "  II  this  spot  is  reached  ttith  no  conflict,  the  current  ACT 

1097  "  is  tentatively  scheduled  starting  at  .CICT. START. 

1098  " 

1099 

1100  il  .COIFLICT  =  0 

1101 

1102  let  lEXT. START. TIME( ACT)  «  .CBCT. START 

1103  let  GACACT)  =  GA(VIS . EVHT) 

1104  let  GA.IIDEX(ACT)  »  GA. IIDEX(VIS.EVBT) 

1106  let  STATUS(ACT)  "TEIT" 

1106 

1107  " 

1108  "  create  a  GA.IR.USE  event  to  prevent  further 

1109  "  uee  of  this  tine  slot 

1110  " 

1111 

1112  let  .OFFSET  ■  .CICT. START  -  SIR .START. TIME 

1113 

1114  lor  i  s  .OFFSET  to  .OFFSET  +  DURATIOM(ACT)  do 

1116  let  CA.USAGE(GA.IIDEX(VIS.EVIT),  .i+1)  = 

1116  concat.l(SV(ACT) ,'7",*AME(ACT)) 

1117  loop 

1118 

1119  endil  "  il  .COIFLICT  0 

1120 

1121  loop  "  next  visibility  VIS. EVHT 

1122 

1123  loop  "  next  .CICT. START. TIME 

1124 

1126  " 

1126  "  Any  activity  involved  in  a  conflict  »ill  arrive  here  still  UH5CHD. 

1127  "  Either  its  PRIORITY  or  IHTERVAL. OFFSET  will  be  increased. 

1128  " 

1129 

1130  il  STATUS(ACT)  =  "UlSCHD" 

1131 
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1132  if  PRIOaiTY(iCT)  <  MAX. PRIORITY 

1133 

1134  add  .PRIORITY. STEP  to  PRIORITY(ACT) 

1136  add  1  to  . PRIORITY . STEP 

1136  lat  STATUS (ACT)  =  "RESCHD" 

1137  lot  .RESCHD. FUG  =  1 

1138 

1139  also 

1140 

1141  let  STATUS (ACT)  =  "MISSED" 

1142  add  IITERVAL. OFFSET. STEP  to  IITERVAL.OFFSET(ACT) 

1143  let  .RESCHD. FLAG  -  1 

1144 

1146  endif  "  PRICRITY(ACT)  <  MAX. PRIORITY 

1146 

1147  endif  "  STATUS  ie  UlSCHD 

1148 

1140  *  > 

1150  ' '  If  a  "conflicting"  entity  baa  just  bad  its  IITERVAL. OFFSET  raised 

1161  ‘‘  to  one-half  ita  default  intarvsd,  the  routine  uill  mark  the  place 

1162  "  in  the  schedule  vhare  the  activity  uould  have  'naturally"  fallen 

1163  '*  (keeping  its  high  priority  and  offset  for  the  data  colection 

1164  "  process).  It  then  increments  the  FAILED  counter,  and  makes  a 

1186  ''  nee  activity  eith  default  priority  and  offset.  This  activity 

1166  "  ia  placed  in  TO . BE . SCHEDULED ,  representing  the  next  tine  this 

1167  "  activity  is  needed  after  the  FAILED  one. 

1168  " 

1168 

1160  if  IITERVAL. OFFSET(ACT)  <=0.6  *  IITERVAL(ACT) 

1161 

1162  file  thia  ACT  in  TO . BE . SCHEDULED 

1163 

1164  else 
1166 

1166  let  STATUS (ACT)  =  "FAILED" 

1167  lot  .i  »  START. TIME( ACT) 

1168  lot  START. TIME (ACT)  »  .i  +  IITERVAL(ACT) 

1160  add  1  to  FAILED 

1170  nov  MAKE. IBH. ACT  giving  ACT  yielding  .lEW.ACT 

1171  subtract  1  from  PRIORITY ( .HEW. ACT) 

1172  file  this  .lEH.ACT  in  PERFORMED 

1173  let  PRIORITY(ACT)  =  0 

1174  let  IITERVAL. OFFSET (ACT)  =  0 

1176  file  this  ACT  in  TO. BE. SCHEDULED 

1176 

1177  endif 

1178 

1179  loop  "lor  every  ACT  in  TO . BE , SCHEDULED 

1180 
1181  " 

1182  ''  If  every  activity  was  scheduled,  the  new  activities  are  updated 
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1183  ‘ '  and  movad  to  PBUFORHEO  to  Ion  th«  basis  ioT  the  next  activity 

1184  ”  selection  process.  II  not.  this  iteration  of  SCHEDULE  is  undone, 

1186  ''  the  activities  Bade  UlSCHD,  then  SCHEDULE  called  again. 

1188  " 

1187 

1188  if  .RESCHO.FLAG  =  0 

1189 

1190  for  every  ACT  in  TO. BE. SCHEDULED  do 

1191 

1192  let  STATUS(ACT)  =  "TEIT" 

1193  let  START. TIME( ACT)  =  HEXT. START. TIME( ACT) 

1194  remove  this  ACT  from  TO .  BE .  SCHEDULED 

1196  file  this  ACT  in  PERFORMED 
1108 

1197  loop 

1198 

1199  nos  PRBSCHEDULE 

1200 

1201  else 

1202 

1203  for  every  ACT  in  TO. BE. SCHEDULED 

1204  with  STATUS(ACT)  =  "TEIT"  do 
1206 

1208  let  .OFFSET  =  MBIT. START. TIHE( ACT)  -  SIM. START. TIME 

1207  for  .i  s  .OFFSET  to  .OFFSET  ♦  DURATIOI(ACT)  do 

1208  let  GA.USAGB(GA.II0BX(ACT),.i^l)  <==  "  " 

1200  loop 

1210 

1211  loop 

1212 

1213  for  every  ACT  in  TO . BE . SCHEDULED , 

1214  let  STATUS(ACT)  =  "UlSCHD" 

1216 

1218  nos  SCHEDULE 

1217 

1218  endif 

1219 

1220  end  ’ 'routine  SCHEDULE 
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A.  10  START. OPS  Process 

1221 

1222 

1223  *  >♦*♦*»♦*•••*••••****♦*♦♦**•••♦•**••***♦*♦♦••♦ 

1224  ' >***********************•*••***************** 

1228  »»**♦♦♦♦•**♦♦**••♦**••****.»*♦•*♦•♦•****••••••• 

1226 

1227  procese  START. OPS 

1228 

1229  ' ' 

1230  "  This  procasa  calls  itself  ever^r  slaniletlon  ainute.  Vhen  called, 

1231  "  it  updates  the  CURREIT.TIHE,  checks  for  available  COITACT 

1232  "  resources  and,  if  any  are  available,  dravs  the  next  ACT  froa 

1233  "  the  SCHEDULED  queue  andassigns  it  to  a  PERFORM. ACT  process. 

1234  ' ' 

1236 

1236  def ins 

1237  .  i 

1238  as  an  integer  variable 

1239 

1240  let  CURREIT.TIME  =  SIM. START. TIME  +  tine.v 

1241 

1242  if  SCHEDULED  is  not  eapty 

1243 

1244  if  u.COITACTd)  >  0 

1245 

1246  for  .i  °  1  to  u.COITACTd)  do 

1247 

1248  for  every  KCT  in  SCHEDULED, 

1240  find  the  first  case 
1260 

1261  remove  this  ACT  froa  SCHEDULED 

1262  activate  a  PERFORM. ACT  giving  ACT  nov 
1363 

1264  loop 

1265  end If 

1266  endif 

1267 

1268  if  CURREIT.TIME  <  SIM. EID. TIME 

1269 

1260  schedule  a  START. OPS  in  1  minutes 

1261 

1262  endif 

1263 

1264  end  "START. OPS 
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A.  11  PERFORM. ACT  Process 


1266 
1266  ' 

1267  *  >0******************************************^^ 

1268  '>**0*000*0*000****00*00*0***00*0000000***00** 

1269 

1270  process  PERFORM. ACT  given  THIS.iCT 

1271 

1272  "  This  process  tskes  the  activity  entity  passed  Iron 

1273  "  START. OPS  and: 

1274  ' ’  -  grabs  one  of  the  COITACT  resources . 

1276  "  -  adds  variation  to  the  activity,  if  required, 

1276  "  -  teats  to  ensure  the  activity  can  be  performed 

1277  "  as  scheduled. 

1278  ”  -*  sisralates  the  perfomance  of  the  valid  activities,  and 

1279  ' '  -  calls  for  a  nes  schedule  if  an  activity  cannot  be 

1280  "  perfomed. 

1281  » ' 

1282  define 

1283  . i , 

1284  .OFFSET,  '*  Minutes  into  sinulation 

1285  .DURATIOI, 

1286  . OFF .  SCHEDULE  *’  Set  to  one  if  activity  cannot  be  perfomed 

1287  as  integer  variables 

1288 

1289  define 

1290  .USB 

1291  as  a  text  variable 

1292 

1293  define 

1294  THIS. ACT 

1295  as  a  pointer  variable 

1296 

1297  request  1  COHTACT(l) 

1298 

1299  ’ ’ 

1300  "  These  statenents  are  nodified  if  activity  duration  variance 

1301  "  is  desired. 

1302  ' ' 

1303 

1304  let  .DURATIOK  =  DURATIOI  (THIS.  ACT) 

1305  let  DURATIOI(THIS.ACT)  =  .DURATIOI 
1308 

1307  let  .OFF. SCHEDULE  =  0 

1308 

1309  ' ' 

1310  ' '  It  is  good  if  the  activity  start  tine  equals  the  current  sim  tine. 

1311  ''  Teat  further  and  take  corrective  action  if  they  are  not  equal. 

1312  " 

1313 

1314  if  START. TIME(THIS. ACT)  ne  CURREIT.TIME 
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1316 

1316  " 

1317  "  If  th«  start  tias  if  later  than  the  cxirrant  tins,  the  process 

1318  "  halts  until  tiste  catches  up.  li  earlier,  check  the  visibility 

1319  ' '  table  and  Gi  use  lor  the  possibility  the  activity  cannot  be 

1320  "  perloraed  nos.  II  it  cannot,  set  the  . OFF . SCHEDULE  llag. 

1321  * ' 

1322 

1323  il  STiRT.TIMECTHIS.ACT)  >  CURREir.TIME 

1324 

1326  salt  START. TIHE(THIS. ACT)  -  CURREIT.TIMB  +  1  minutes 

1326 

1327  else 

1328 

1329  let  .OFFSET  =  CURREIT.TIME  -  SIM. START. TIME 

1330 

1331  lor  .i  =  .OFFSET  to  .OFFSET  +  DURATIOKTHIS . ACT) 

1332  Bhile  . OFF . SCHEDULE  =  0  do 

1333 

1334  lot  every  VIS.EVIT  in  VIS. TABLE 

1336  sith  GA(VIS.EVrD  =  GA (THIS. ACT)  and 

1336  SVC VIS.EVIT)  =  SV (THIS. ACT)  and 

1337  RISE.TIMECVIS.EVIT)  >=  CURREIT.TIME  ♦  (.i  -  .OFFSET)  and 

1338  SET.TIMB(VIS.EVIT)  <=  CURREIT.TIME  ♦  (.i  -  .OFFSET) 

1339  lind  the  lirst  case 

1340  il  none 

1341 

1342  lot  .OFF. SCHEDULE  =  1 

1343 

1344  endil 
1346 

1346  let  .USE  =  GA.USAGE(GA.IIDEX(THIS.ACT),  .i-i-1) 

1347  il  .USE  ne  "  "  and  .USE  ne  SV(THIS.ACT) 

1348 

1349  let  .OFF. SCHEDULE  »  1 
1360 

1351  endil 

1362  loop 

1363  endil 

1364  endil 
1366 

1366  il  .OFF. SCHEDULE  =  0 

1367 

1368 

1369  "  The  activity  can  be  perlormed  ncB...hold  on  to  the  resource 

1360  "  lor  the  duration  ol  the  activity,  then  lile  the  activity  in 

1361  "  PERFORMED. 

1362 

1363 

1364  let  START. TIMECTHIS. ACT)  =  CURREIT.TIME 
1366  let  STATUS (THIS. ACT)  =  "PERF" 
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1366 

1367  salt  DURATIOI (THIS. ACT)  ainates 
1366  relinquish  1  COITACT(l) 

1369  lile  THIS. ACT  in  PBBFORMBO 

1370 

1371  else 

1372 

1373  ’  ’ 

1374  ' '  Remove  the  the  scheduled  activities  from  SCHEDUT.ED,  clear 

1376  **  their  GA  reservations  from  GA. USAGE,  give  up  the  COITACT 

1376  ''  token,  and  call  PRESCHBOULE  to  create  a  nes  schedule. 

1377  » ' 

1378 

1379  for  every  ACT  in  SCHEDULED 

1380  with  START. TIHE( ACT)  >=  CURREHT . TIME  do 

1381 

1382  remove  this  ACT  from  SCHEDULED 

1383 

1384  let  .OFFSET  =  START. TIHB( ACT)  -  SIM. START. TIME 
1386 

1386  for  .i  =  .OFFSET  to  .OFFSET  +  DURATIOH(ACT)  do 

1387  let  GA.USAGE(GA.IHDEX(ACT),.i+l)  =  " 

1388  loop 

1389 

1390  destroy  this  ACT 

1391 

1392  loop 

1393 

1394  relinquish  1  COITACT(l) 

1396  nos  PRESCHEDULE 

1396 

1397  endif 

1398 

1399 

1400  end ’’PERFORM. ACT 
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A. 12  REPORT.QUEUES  Routine 

1401 

1402  ’  >**«*4i*«*««#**«4i*i**«*i^4i*«4i*****«4i«*4i«4i4t«««#4i* 

1403  *  '**«4>**4>*«*********«#**<«i*«*«***^*«*********** 

1404  '  '*«*«**««««<«>*«4'*«4i%*4>*«««*****««**«***>>**«*4>4> 

1406 

1406  routine  REPORT . QUEUES 

1407 

1408  " 

1409  Thie  routine  prints  the  contents  of  the  syatens  queues. 

1410  ’• 

1411 

1412  define 

1413  .i. 

1414  .j 

1416  as  integer  variables 

1416 

1417  print  1  line  eith  CURREIT.TIME  thus 
REPORT  QUEUES:  Current  time  =  *****tr 

1419 

1420  if  SCBEOULEO  is  not  empty 

1421  print  2  lines  thus 
SCHEDULED: 

START  (lEXT)  SV/ACT  DUR/IBT  PRI/OFFSET  GA 

1424  for  each  ACT  in  SCHEDULED  do 
1426  print  1  line  sith 

1426  trunc.f(START.TIHE(ACT)/1440), 

1427  trunc .  f  (f  rac .  f  (START . TmE(ACT)/1440)*24) . 

1428  nod-f (mod. f( START. TIME( ACT) ,1440) ,60) , 

1429  trunc. fdBXT. START. TIME(ACT)/1440)  , 

1430  trunc . f (f rac . f (lEXT . START .TH1E{ACT)/1440)*24) , 

143 1  siod . f (mod . f ( lEXT . START . TIHE ( ACT) , 1440) , 60 ) , 

1432  SV(ACT) , 

1433  IAI(E(ACT) , 

1434  DURATIOI(ACT), 

1436  IITERVAL(ACT) , 

1436  PRIORITY(ACT) , 

1437  IITERVAL.OFFSET(ACT), 

1438  GA(ACT)  thus 

ees/«e:«e  (*e«/ee;«*)  eeeeeeeeeee/eeeeee  *•/*♦***  «*/««« 

1440  loop 

1441  endif 

1442 

1443  if  TO . BE . SCHEDULED  is  not  empty 

1444  print  2  lines  thus 
TO. BE. SCHEDULED: 

START  (lEXT)  SV/ACT  DUR/IIT  PRI/OFFSET  GA 

1447 

1448  for  each  ACT  in  TO . BE . SCHEDULED  do 

1449  print  1  line  sith 

1460  trunc . f (START . TIME( ACT) /1440) . 
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1461  trunc . 1 (f rac . 1 (START . TIKBC ACT)/1440) *24) , 

1462  ■od.l(«od.l (START. TIKE( ACT) .1440) .60) . 

1463  trunc.  KIEXT.  START.  TIMB(  ACT)/ 1440). 

1464  trunc. Kfrac.KIKXT. START. TTME(ACT)/1440)*24)  , 

1466  nod. Knod.KlEXT. START. TIKE(ACT). 1440). 60)  , 

1466  SV(ACT), 

1467  lAMB(ACT) . 

1468  DURATIOI(ACT), 

1460  IITBRVAL(ACT) . 

1460  PRIORITY (ACT). 

146 1  IITERVAL . OFFSET ( ACT) . 

1462  GA(ACT)  thus 

a**/**:**  (•••/**:••)  •••••«**«••/••**•«  *#/*••♦•  ••/•** 

1464  loop 
1466  «Bdif 

1466 

1467  if  PERFORMED  ia  not  anpty 

1468  print  2  linaa  thua 
PERFORMED; 

START  (MBIT)  SV/ACT  DUR/IIT  PRI/QFFSET  GA 

1471  for  aach  ACT  in  PERFORMED  do 

1472  print  1  lina  «ith 

1473  trunc. f (START. TIME(ACT)/1440). 

1474  trunc . f (f rac . f (START . T1KE( ACT) /1440)*24) . 

1476  nod . f (nod . f (START . TIHB( ACT) . 1440 ) . 60) , 

1476  trunc . f (MBIT . START . TIME( ACT)/1440) , 

1477  trunc . f (f rac . f (lEXT . START .TIME(ACT) /1440) *24) , 

1478  nod. f  (nod. fdEXT. START. TIKE(ACT), 1440), 60), 

1479  SV(ACT). 

1480  lANE(ACT) , 

1481  DURATIOI(ACT) , 

1482  IITBRVAL(ACT) , 

1483  PRIORm(ACT) . 

1484  IBTERVAL . 0FFSET( ACT) , 

1486  GA(ACT)  thua 

••a/aa:*a  (aa*/««;a*)  ***** 

1487  loop 

1488  andif 

1489 

1400  if  UISCHED'JLED  ia  not  empty 
1491  print  2  lines  thus 
UlSCHEOULBD : 

start  (IEXT)  SV/ACT  DUR/IBT  PRI/IBT. OFFSET 

1404  for  each  ACT  in  UlSCHEDULED  do 
1496  print  1  line  aith 

1496  trunc . f (START . TIME( ACT) /1440) . 

1497  trunc.f(frac.f (START, TIHE(ACT)/1440)*24) , 

1498  mod . f (mod . f (START . TIME( ACT) , 1440 ) , 60) . 

1499  trunc  .fdEIT .  START  .TIHE(ACT)/1440)  , 

1600  trunc . f (frac . f (BEIT. START .TIME(ACT)/1440)*24) , 

1601  mod. Kmod.KHEXT. START. TIME(ACT), 1440), 60) , 


1602  SV(ACT). 

1603  lANECACT) , 

1604  DU&ATIOKACT). 

1505  IITERVAL(ACT) , 

1606  PRIQRITY(ACT) , 

1607  IITERVAL. OFFSET (ACT)  thua 
(.***/**:**) 

1609  loop 

1610  eadil 

1611 

1612  and  "  REPORT . QUEUES 
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A. 13  REPORT.  USE  Routine 


1513 

1614  ‘  •****it*/*****0***********m******************** 

1515  * ‘t^******************************************* 

1516  ' >****t******^t‘******************************* 

1617 

'618  routine  REPORT. USE 

1619 

1620  ' * 

1621  ' ’  This  routine  prints  the  GA  use  array  to  the  standard 

1622  ''  output  file.  Kinutes  if  no  GA  in  use  are  not  printed. 

1623  '  • 

1624 

1626  define 

1626  .i. 

1627  .  j 

1628  as  integer  variables 

1629 

1630  print  1  line  eith  CURREHT.TINE  thus 

REPORT  USE:  Current  time  =  ♦♦***♦ 

1632 

1633  for  .i  =  1  to  SIM. EfD. TIME  -  SIM. START. TIME  do 

1634  let  .j  =  .i  +  144000 
1636 

1636  if  GA.USAGE(l,.i)  ne  "  "  or 

1637  GA.USAGE(2,.i)  ne  "  "  or 

1638  GA.USAGEO,  i)  ne  "  "  or 

1639  GA.USAGE(4,.i)  ne  "  "  or 

1640  GA.USAGE(5,.i)  ne  ” 

1641 

1642  print  1  line  vith 

1643  tnmc.f  ( .  j/1440) , 

1644  trunc.f(frac.f(. j/1440) ♦24), 

1646  Bod.fCBOd.fC. j,1440),60), 

1646  GA.USAGE(l,.i), 

1647  GA.USAGE(2, .i) , 

1648  GA.USAGE(3,  .i)  , 

1649  GA.USAGE(4,  .i) , 

1660  GA.USAGE(6,.i}  thus 

♦♦♦/♦♦;♦♦  «******«•* 

1652  endif 
1563  loop 
1664 

1666  end  "REPORT.  USE 


.\-36 


A.f4  REPORT.  VIS  Routine 

1666 

1667  ‘  >*************'i**********iii***4*************** 

1668  ’  '  ******tr**************************‘*****4r**** 

1669  >  >*««i«#**4>********-^  .  •4r***«*«**«**«#«**«*«**4i* 

1660 

1661  routine  REPORT. VIS 

1662 
1603  " 

1664  “  This  routine  prints  the  visibility  table  to  the  standard 

1666  "  output  file. 

1660  '  ’ 

1667 

1568  print  1  line  vith  CURRENT. TIME  thus 
REPORT  VIS;  Current  time  =  *♦♦♦♦* 

1670 

1671  for  each  VIS.EVHT  in  VIS. TABLE  do 

1672  print  t  line  with 

1673  trunc . f (RISE . TIME( VIS . EVBT)/1440) . 

1 674  trunc . f (irac . f (RISE . TIME( VIS . EVHT) /1440) »24) , 

1676  trunc  i ■ rac .f (frac . f (RISE.T1ME(V1S .EVHT)/I440)*24)*e0) , 

1670  trur-  .'.'I  TIME(VIS.EVIT)/1440). 

1677  trunc. t!;  ac.f(SET.TIME(VIS.EVBT)/1440)*24) , 

1678  trunc . t (frac . f (frac . t (SET .TIME(VIS . EVHT)/1440)»24) *60) , 

1676  RISE.TIME(VIS.EVBT) . 

1680  SET.TIMR(VIS.EVaT) , 

1681  GA(VIS.EVBT), 

1682  GA.IBDEX(VIS.EVBT) , 

1683  SV(VIS.EVBT)  thus 

««*/««;««  *••/«•;*•  (•**•«««-««««•«)  *««*(«)  seeee* 

1686  loop 
1686 

1687  end  ”  REPORT. VIS 


A.  15  ANALYSIS  Routine 


1688 

1689  '  '•*****««*t|i******4>**4i«4i«******4i«*««#4>i»4i*«**«* 

1690  ’  ’***iH‘****mmm>f***********4******************* 

1691  ' '******************************************** 

1592 

1693  routine  ANALYSIS 

1694 

1696  ' ' 

1696  ’’  This  routine  princ  the  simulation  conditions,  pe^ameters,  and 

1697  ''  Bummavizes  the  results  in  terns  oT  the  predefined 

1698  ''  performance  measures.  The  output  is  saved  to  the  filename 

1699  "  defined  by  OUT. FILE. 

1600  ’  ’ 

1601 

1602  define 

1603  ,i. 

1604  .GA. INDEX, 

1606  .START. TIME. 

1606  .DURATION, 

1607  .j. 

1608  .RESV.TEMP, 

1609  .UTIL. TEMP 

1610  as  integer  variables 

1611 

1612  define 

1613  .CAUSE 

1614  as  a  text  variable 
1616 

1616  open  unit  3  for  output, 

1617  name  is  OUT. FILE 

1618  use  \init  3  for  output 

1619 

1620  ' ’ 

1621  ”  This  crude  but  effective  routine  scans  the  GA.USE  array  and 

1622  ’’  results  in  utilization  statistics  for  individual  and  total 

1623  "  GA  use. 

1624  ’ ' 

1626 

1626  for  .i  =  1  to  SIM. END. TIME  -  SIM. START. TIME  do 

1627 

1628  let  .UTIL. TEMP  =  0 

1629  let  .RESV.TEMP  =  0 

1630  if  substr.fCGA.USACECl,  .i),l,l'/  -  ’B" 

1631  let  ASCH.UTIL  =  1 

1632  add  1  to  .UTIL. TEMP 

1633  else 

1634  let  ASCH.UTIL  =  0 

1835  endif 

1636  if  substr.f(GA.USAGE(l,.i),l,l)  ne  "  " 

1637  let  ASCH.RESV  =  1 
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1638  add  1  to  .RESV.TBMP 

1639  «l8« 

1640  let  ASCR.RESV  =  0 

1641  endlf 

1642  il  8ub8tr.i(GA,USAGE(2, .i),l,l)  =  "B" 

1643  let  CAPE. UTIL  =  1 

1644  add  1  to  .UTIL. TEMP 

1646  el8e 

1646  let  CAPE. UTIL  =  0 

1647  endlf 

1648  if  8Ub8tr.l(GA.USAGE(2..i),l,l)  ne  "  *• 

1649  let  CAPE.RESV  =  1 

1660  add  1  to  .RESV.TEMP 

1661  else 

1662  let  CAPE.RESV  =  0 

1663  endlf 

1664  If  8ub8tr.f(GA.USAGE(3, .1) ,1,1)  =  "B" 

1666  let  DIEG.UTIL  =  3 

1666  add  1  to  .UTIL. TEMP 

1657  else 

1668  let  DIEG.UTIL  =  0 

1669  endlf 

1660  11  8Ub8tr.f(GA.USAGE(3, .i),l,l)  ne  ”  " 

1661  let  DIEG.RESV  *  1 

1662  add  1  to  .RESV.TEMP 

1663  else 

1664  let  DIEG.RESV  =  0 
1666  endlf 

1666  11  8Ub8tr.l(GA.USAGE(4, .i),l,l)  =  "B" 

1667  let  KWAJ.UTIL  «  1 

1668  add  1  to  .UTIL. TEMP 

1669  else 

1670  let  KWAJ.UTIL  =  0 

1671  endlf 

1672  11  8Ub8tr.l(GA.USAGE(4, .i),l,l)  ne  "  " 

1673  let  KWAJ.RESV  =  1 

1674  add  1  to  .RESV.TEMP 
1676  else 

1676  let  KWAJ.RESV  =  0 

1677  endlf 

1678  11  substr.f (GA.USAGE(E, .i),l,l)  =  "B" 

1679  let  PIKE. UTIL  =  1 

1680  add  1  to  .UTIL. TEMP 

1681  else 

1682  I'lt  PIKE. UTIL  =  0 

1683  endlf 

1684  if  8ubstr.l(GA,USAGE(6,  .i),l,l)  ne  "  •' 

1686  let  PIKE.RESV  =  1 

1686  add  1  to  .RESV.TEMP 

1687  else 

1688  let  PIKE.RESV  =  0 
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1689  «ndif 

1690  let  UTIL  =  .UTIL. TEMP 

1691  let  RESV  s  .RESV.TENP 

1692  print  1  line  vith 

1693  .i, 

1694  .UTIL. TEMP  thus 
«**«««  e 

1696 

1697  loop 

1698 

1699  print  1C  lines  sith 

1700  START. DAY, 

1701  START.hr, 

1702  START.MIH, 

1703  BID. DAY, 

1704  EHD.HR, 

1706  EID .  MIH , 

1706  SIM. START. TIME, 

1707  SIM. E«D. TIME, 

1708  lUM.OF.SV, 

1709  lUM.OF.GA, 

1710  lUM.SIMUL.COiTACTS, 

1711  RBMARKl, 

1712  REMARX2, 

1713  REMARX3  thus 

SCHEOULIIG  IIPUTS 

TINE:  ««*/«*;**  to  (*«««««  to  ******) 

•  ♦  SVs 
e*  GAs 

*  Max  contacts 


1724  open  unit  2  for  input, 

1726  naae  is  OUTAGE. FILE 

1726 

1727  use  unit  2  lor  input 

1728 

1729  read 

1730  REMARK 1 , 

1731  RENARK2 

1732  as  2  T  ♦ 

1733 

1734  read  .  i 
1736 

1736  print  1  line  with  BUM.OF.OUTAGjOS  thus 
e*  Prescheduled  outages : 

1738 

1739  if  lUM. OF. OUTAGES  >  0 


.■\  10 


1740 

1741  print  2  lines  thus 

Index  Start  Duration  Caueo 

1744  for  .i  =  1  to  lUM . OF . OUTAGES  do 

1745 

1746  read 

1747  .GA.IIDEX, 

1748  .START. TIME. 

1749  .DURATIOI, 

1760  .CAUSE 

1761 

1762  print  1  line  with 

1763  .GA.IIDEX. 

1764  .START. TIME, 

1766  .DURATIOI, 

1766  .CAUSE  thus 

•  *«eee«  ««•*  e^e**************** 

1768 

1766  loop 

1760  endll 

1761 

1762  close  unit  2 

1763 

1764  print  4  lines  thus 
RESULTS ; 

lunber  Max  Min  Mean  Std  Dev 


1769 

print  6  lines  «lth 

1770 

NMBR. OFFSET, 

1771 

MAX. OFFSET, 

1772 

Mil. OFFSET, 

1773 

MI. OFFSET, 

1774 

STD. OFFSET, 

1776 

IMBR.PRI, 

1776 

MAX.PRI, 

1777 

MII.PRI, 

1778 

MI.PRI, 

1779 

STD.PRI, 

1780 

IMBR.UTIL, 

1781 

MAX. UTIL, 

1782 

Mil. UTIL, 

1783 

MI. UTIL, 

1784 

STD, UTIL, 

1786 

INBR.RESV, 

1786 

NAX.RESV, 

1787 

MII.RESV, 

1788 

MI.RESV, 

1789 

STD.RESV, 

1790 

FAILED  thus 
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OFFSET: 

PRIORITY: 

GA  UTIL; 

OA  RESV; 

***** 

**** 

** . 

FAILED  SUPPORTS:  ♦♦ 

1797  print  4  linas  thus 


OFFSET: 

V&lua  luBbar  Percent 

1802  lor  .1  =  1  to  26  do 

1803  print  1  line  eith 

1804  (.i-l)elO, 

1806  HIST. OFFSET (.i). 

1806  100*HIST.0FFSET(.i)/IMBR. OFFSET  thus 

«  •ee.ee 

1808  loop 

1809 

1810  print  4  lines  thus 
PRIORITY: 

Value  lumbar  Percent 

1816  lor  .1  =  1  to  12  do 

1816  print  1  line  with 

1817  .1-1, 

1818  HIST.PRI(.i) , 

1819  100«HIST.PRI(.i)/RMBR.PRI  thus 

a  a««e  eaa.aa 

1821  loop 

1822 

1823  print  10  lines  vith 

1824  NI.AUTIL*100, 

1826  MI.ARESValOO, 

1826  STD.AUTIL*100, 

1827  STD.ARESValOO, 

1828  HI.CUTIL*100, 

1829  MI.CRBSValOO, 

1830  STD.CUTIL*100, 

1831  STD.CRF.GI'alOO, 

1832  HI. DU* *100, 

1833  MI.DRC3V4100, 

1834  STD.DUl'ILalOO, 

1836  STD.DRESV*100, 

1836  m.KUTILaiOO, 

1837  MH.KRESValOO, 

1838  STD.KUTIL*100, 

1839  STD.KRESValOO, 

1840  MI.PUTIL*100, 

1841  NH.PRESVaiOO, 
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1842  STD.PUTIL*100. 

1843  STD.PRESV^IOO  thua 

lIDIVIDUiL  Gi  UT1LIZATI0I(SV)/RESERVATI0I(ALL): 
GA  X  ttsad/rasv  atd  usad/raav 


ASCI 

«*. *«/*•. 

CAPE 

DIBG 

KWAJ 

PIKE 

.**/** .** 

18S4  print  4  linae  thus 

GA  UTILIZATION ( SV) /RESBRVATIOI CALL): 

Valua  lumbar  ’’arcant 

1869  lor  .i  =  1  to  6  do 

1860  print  1  lina  nith 

1861  .i-1, 

1862  HIST.UTIL(.i), 

1863  HIST.RESVC.i), 

1864  100*HIST.UTIL(.i)/IMBR.UTIL, 

1866  100«BIST.RBSV(.i)/INBIl.RESV  thus 


1867 

loop 

1868 

1869 

closa  unit  3 

1870 

1871 

and’ 'AIALYSIS 
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A.  16  VALIDATE  Rouitne 


1872 

1873 

1874 

1876 

[#««««« 

1876 

I****** 

1877 

1878 

roDtina  VALIDATE 

1870 

1880 

1  1 

1881 

' '  This  roatins  is  nssd  only  during  ths 

siaulation  validation  step 

1882 

’ ’  to  proTids  quantativs  nsasurs  of  tho 

ability  of  the  simulation  ^ 

1883 

'*  duplicats  the  MCS  schsdallng  results. 

The  file  "valact.dat" 

1884 

’ '  contains  a  sat  of  "real"  NCS-schaduled  activities  for  the 

1886 

"  validation  period:  the  validation  results  are  uritten  to  the 

1886 

”  file  pointed  to  by  VAL.OUT. 

1887 

1  1 

1888 

1889 

define 

1800 

•  i. 

1891 

.START. TIKE, 

1892 

.DURATIOI, 

1803 

.BLOCK, 

1804 

.IITBRVAL, 

1896 

■PRIORITY, 

1806 

.VARIAICB, 

1807 

.CRITICALITY, 

1898 

.GA.FUG. 

1899 

.lUN.OF.VAUCTS 

1900 

as  integer  variables 

1901 

1902 

define 

1003 

.CAUSE, 

1904 

CA. 

1006 

.SV.IAHE, 

1906 

.ACT.IAME 

1907 

as  text  variables 

1008 

1009 

open  unit  2  for  input, 

1910 

uane  is  "valact.dat" 

1911 

use  unit  2  for  input 

1912 

1913 

open  unit  3  for  output. 

1914 

nano  is  VAL.OUT 

1916 

use  unit  3  for  output 

1916 

1917 

f  » 

1918 

''  Here  is  a  excerpt  from  a  "valact.dat 

"  file; 

1919 

"  67  ".lUM.OF.VALACTS" 

1920 

"  BI-008  1  lAV  144660  6  1  1 

1440  CAPE 

1021 

"  BI-008  1  SOH  144200  10  1  1 

480  DIEG 
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1922  *  '  BI-009  1  lAV  144146  6  1  1  1440  CAPE 

1923  "  .SV.IAKE,  .BLOCK,  .ACT.IAME,  .START. TIME,  .DURATIOR, 

1924  "  .VARIAICE,  .CRITICALITY,  .IITBRVAL,  .GA 

1926  » * 

1926 

1927  read  .  BUM .  OF .  VALACTS 

1928  lor  .i  =  1  to  . lUM . OF . VALACTS  do 

1929 

1930  read 

1931  .SV.IANB, 

1932  .BLOa, 

1933  .ACT.IAME, 

1934  .START.  TIME, 

1936  .DURATIOI, 

1936  .VARIAICE, 

1937  .CRITICALITY, 

1938  .IITERVAL, 

1939  .QA 

1940 

1941  " 

1942  "  The  first  activity  entity  in  the  SCHEDULED  queue  that 

1943  “  Batches  the  current  validation  activity  is  referenced. 

1944  "  the  diffsrence  betsesn  the  tvo  start  tiaes  is  found  and 

1946  ‘ '  a  counter  is  Increaented  if  the  system  scheduled  the  same 

1946  "  GA  that  was  used  in  reality.  A  TALLY  statement  is  tracking 

1947  "  value  of  the  START .  OFFSET . 

1948  " 

1949 

1960  for  every  ACT  in  SCHEDULED 

1961  with  SV(ACT)  «  .SV.IANE  and 

1662  lANECACT)  =  .ACT.IAME  and 

1963  START. TINE(ACT)  >-  SIN. START. TIME 

1964  find  the  first  case 

1966  if  found 

1966 

1967  let  START. OFFSET  =  abs . f (. START . TIME  -  START. TIME( ACT)) 

1968  if  .GA  s  GA(ACT) 

1969  add  1  to  .GA.FLAG 

1960  endif 

1961  endif 

1962  loop 

1963 

1964  print  10  lines  vitb 

1966  START.  DAY, 

1966  START.hr, 

1967  START. Mil, 

1968  EID.DAY, 

1969  BID. HR, 

1970  EID.MII, 

1971  SIN. ST ART. TIME, 

1672  SIN.  EID.  TIME, 
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1973  ItJH.OF.SV, 

1974  lUN.OF.GA, 

1976  lUN.SINUL.COITACTS. 

1976  REMARKl , 

1977  RENA11K2, 

1978  REMARKS  thus 

SCHEDULIIG  IIPUTS 

TINE:  ***/**:**  to  *#«/**:•*  (*««•**  to  ******) 
**  SVs 
*♦  GAe 

*  Max  contacts 


1989  print  4  lines  thus 
VALIDATIOI  RESULTS: 

Ituiher  Max  Min  Mean  Std  Dev 

1994  print  4  lines  «ith 
1996  IMBR. START. OFFSET, 

1996  MAX. ST ART. OFFSET, 

1097  Nil. ST ART. OFFSET, 

1998  Mt. START. OFFSET, 

1999  STD. START. OFFSET, 

2000  .GA.FUG  thus 

START  OFFSET:  eeeee  e*««  eeee  ae.eeee  •*,«*** 
GA  NATCH ;  ••*** 

2006  print  4  lines  thus 

ACTIVITY  START  OFFSET: 

Value  luaber  Percent 

2010  for  .i  =  1  to  21  do 

2011  print  1  line  vith 

2012  (.i-D  +  lO, 

2013  HIST.SO(.i), 

2014  100eHIST.SO(.i)/IMBR. START. OFFSET  thus 

*  mm*.** 

2016  loop 

2017 

2018  close  unit  2 

2019  close  unit  3 

2020 

2021  end  "VALIDATE 
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Appendix  B.  MCS  Simulation  Example  Input  Data. 


B.l  Overview. 

This  appendix  describes  the  input  data  used  during  a  typical  experimental  run  of  the  simu¬ 
lation  program.  As  the  total  experimental  suite  was  108  runs,  with  each  set  of  input  data  different 
for  each  run,  it  is  not  practical  to  provide  the  complete  input  data  array  here.  However,  the  input 
data  modification  process  required  to  duplicate  the  experimental  results  is  described  in  Chapter  4. 
The  purpose  auid  use  of  the  various  data  is  described  in  Chapter  3  and  the  comments  contained 
in  the  MCS.SIM  program  listing.  Appendix  A.  General  notes  are  provided  with  the  listing  of  each 
data  set. 

B.2  Simulation  VAX  Command  File. 

This  is  not  input  data  per  ae,  but  one  of  the  command  files  used  to  direct  the  execution  of  the 
simulation  runs.  The  MCS.SIM  program  was  executed  on  the  Air  Force  Institute  of  Technology 
Digital  Equipment  Corporation  VAX  6420  (9:8.1).  The  default  method  for  submitting  SIMSCRIPT 
programs  on  this  system  does  not  easily  allow  batch  submissions,  so  the  following  simple  command 
file  was  created  to  speed  the  experiment  process.  Each  input  file  was  prepared  in  advance  to  specify 
the  appropriate  input  and  output  files. 


t  dallne/user  syalinput  8l6.dat 
$  dafina/usar  syeSoutput  s 16. out 
t  run  ucs 

t  dafine/nser  aystinput  8l7.dat 
t  daline/user  sysloutput  817. out 
$  run  Bcs 

t  dalin«/a8ar  ay8tinput  s 18.dat 
$  dallna/u8ar  aystoutput  8 18. out 
t  run  BCS 

i  dellna/usar  8y8$input  8l9.dat 
$  dafina/uaar  syaloutput  sl9.out 
$  run  BC8 

(  dalina/usar  ayslinput  820.dat 
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I  d«llii«/u8er  sysloutput  s20.out 
$  inn  nc8 

t  delin8/u8er  8y8tiuput  821.dat 
$  d8lin«/u8ar  systoutpnt  821. out 
t  run  ncc 

t  d«lin«/u8er  syatinput  822.dat 
t  deline/uaer  sysloutput  822. out 
9  run  Bcs 

9  dallne/user  syslinput  823.dat 
9  dallna/usttr  sysloutput  a23.out 
9  run  ucs 

9  dsline/uaer  syslinput  s24.dat 
9  dalius/asar  sysloutput  e24.out 
9  run  DCS 


B.S  Simulation  Parameter  Datn 

The  following  data  is  maintained  in  the  SIMSCRIPT  system  default  input  datafile.  For  the 
V'AX  implementation  of  SIMSCRIPT,  this  is  the  file  specified  by  the  user  in  response  to  the  “Enter 
name  of  Input  File  (.DAT  assumed)  (ie.  DATAl)”  request  of  the  RUNSIM  start  program.  When 
using  the  command  file  listed  in  Section  B.2,  the  SIMSCRIPT  executive  will  read  the  data  file 
defined  aa  the  default  system  input  (e.g.,  “824.dat”). 


visall .dat 
tiss.dat 
outaga.dat 
act24.dat 
r24 . out 
val . out 

"Mo  GA  uaint  -  no  jlOO  CPU  outage" 
"Pike  fuxl  availability" 

"24  SVs" 


Visibility  Data 


This  data  describes  the  visibility  periods  between  satellite  vehicle  and  ground  antenna  pair.s. 
The  data  used  for  the  validation  and  testing  of  this  MCS  Simulator  was  created  by  the  program 
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Pass  Scheduler  (B).  A  description  of  Pass  Scheduler  amd  the  process  used  to  create  the  data  below 
is  described  in  Appendix  D. 


B  90 

ASCI  1 
BII-26 

9 

18 

39 

1 

11 

BII-09 

9 

19 

6 

1 

9 

BII-27 

9 

20 

32 

3 

11 

BII-01 

9 

20 

43 

3 

16 

BII-13 

9 

21 

3 

2 

32 

BII-04 

9 

22 

14 

7 

2w 

BI-OOB 

9 

22 

38 

64 

BII-06 

9 

23 

24 

6 

3 

BII-02 

10 

0 

39 

9 

62 

BIl-29 

10 

0 

66 

7 

30 

BIl-09 

10 

1 

9 

6 

60 

BI-009 

10 

3 

26 

12 

31 

BIl-26 

10 

S 

6 

11 

62 

EII-14 

10 

6 

6 

9 

7 

BII-U 

10 

6 

31 

13 

14 

BII-03 

10 

6 

47 

13 

21 

Bl-OlO 

10 

7 

31 

14 

19 

BII-14 

10 

9 

7 

16 

46 

BII-02 

10 

9 

16 

10 

10 

BII-07 

10 

10 

4 

16 

49 

BII-06 

10 

10 

16 

19 

33 

BII-30 

10 

10 

34 

17 

13 

BII-10 

10 

11 

19 

20 

34 

BI-OU 

10 

11 

38 

17 

68 

BI-009 

10 

11 

87 

12 

31 

Bl-OlO 

10 

13 

6 

18 

23 

BII-08 

10 

13 

14 

22 

28 

BII-13 

10 

16 

41 

20 

49 

aiI-12 

10 

16 

3 

22 

40 

BII-07 

10 

16 

49 

20 

40 

BI-008 

10 

16 

62 

22 

34 

BII-28 

10 

16 

62 

23 

21 

BII-28 

10 

18 

35 

1 

6 

BlI-09 

10 

19 

1 

1 

6 

BII-10 

10 

19 

58 

20 

43 

BII-27 

10 

20 

28 

3 

7 

BII-01 

10 

20 

38 

3 

12 

BII-13 

10 

20 

68 

2 

27 

BII-04 

10 

22 

10 

7 

21 

BI-008 

10 

22 

34 

3 

50 

Bii-oe 

10 

23 

20 

6 

59 

BII-02 

11 

0 

34 

9 

12 

BII-29 

11 

0 

61 

7 

26 

H-3 


Bll-Od 

11 

1 

6 

6 

46 

Bl-009 

11 

3 

22 

11 

63 

BII-26 

11 

6 

2 

11 

48 

BII-14 

11 

6 

2 

9 

2 

BII-11 

11 

6 

27 

13 

9 

BII-03 

11 

6 

43 

13 

17 

Bl-OlO 

11 

7 

27 

14 

16 

Bn-14 

11 

9 

2 

IS 

42 

BII-02 

11 

9 

12 

10 

6 

BII-07 

11 

10 

0 

16 

46 

BII-06 

11 

10 

12 

19 

29 

BII-30 

11 

10 

30 

17 

9 

BII-10 

11 

11 

15 

19 

64 

BI-011 

11 

11 

34 

17 

64 

BI-009 

11 

11 

63 

12 

27 

Bl-OlO 

11 

13 

2 

18 

19 

BIl-08 

11 

13 

10 

22 

24 

BII-13 

11 

16 

36 

20 

46 

BII-12 

11 

16 

69 

22 

36 

BII-07 

11 

16 

46 

20 

36 

BI-008 

11 

16 

48 

22 

30 

BII-28 

11 

16 

48 

23 

17 

BII-26 

11 

18 

31 

1 

2 

BII-09 

11 

18 

67 

1 

0 

BII-10 

11 

19 

64 

20 

39 

BII-27 

11 

20 

24 

3 

3 

BII-01 

11 

20 

34 

3 

8 

BII-13 

11 

20 

64 

2 

23 

BII-04 

11 

22 

6 

7 

17 

BI-008 

11 

22 

30 

3 

46 

BII-06 

11 

23 

16 

6 

66 

BII-02 

12 

0 

30 

9 

7 

BII-29 

12 

0 

47 

7 

22 

BII-09 

12 

1 

0 

6 

41 

BI-009 

12 

3 

18 

11 

49 

BII-26 

12 

4 

68 

11 

44 

BII-14 

12 

4 

68 

8 

68 

BII-11 

12 

6 

23 

13 

6 

BII-03 

12 

6 

40 

13 

13 

Bl-OlO 

12 

7 

23 

14 

11 

BII-14 

12 

8 

68 

16 

37 

BII-02 

12 

9 

7 

10 

2 

BII-07 

12 

9 

66 

16 

41 

BII-06 

12 

10 

8 

19 

26 

BII-30 

12 

10 

26 

17 

6 

BII-10 

12 

11 

11 

19 

SO 

BI-Oll 

12 

11 

30 

17 

60 

m-009 

12 

11 

49 

12 

23 

Bl-OlO 

12 

12 

63 

18 

16 

BII-08 

12 

13 

6 

22 

20 

BII-13 

12 

16 

32 

20 

40 

B-i 


BIT-12 

12 

16 

66 

22 

32 

BII-07 

12 

16 

41 

20 

32 

Bl-OOb 

12 

16 

44 

22 

26 

BII-28 

12 

16 

44 

23 

13 

BII~26 

12 

18 

27 

0 

68 

BlI-09 

12 

18 

63 

0 

66 

'  BII-10 

12 

19 

60 

20 

36 

BII-27 

12 

20 

20 

2 

69 

BII-01 

12 

20 

30 

3 

4 

BII-13 

12 

20 

60 

2 

19 

BII-04 

12 

22 

2 

7 

13 

BI-C08 

12 

22 

26 

3 

42 

BII-06 

12 

23 

12 

6 

61 

BII-02 

13 

0 

26 

9 

3 

BII-29 

13 

0 

43 

7 

18 

BII-oo 

13 

0 

66 

6 

37 

Bl-'jOii 

13 

3 

14 

11 

48 

BII-25 

13 

4 

S3 

11 

40 

BII-14 

13 

4 

64 

8 

64 

Bil-ll 

13 

6 

19 

13 

1 

BII-03 

13 

6 

36 

13 

9 

Bl-OlO 

13 

7 

19 

14 

6 

BII-14 

13 

8 

64 

16 

33 

El 1-02 

13 

0 

3 

9 

68 

BII-07 

13 

9 

62 

16 

37 

BlI-06 

13 

10 

4 

19 

21 

BII-30 

13 

10 

21 

17 

1 

BII-10 

13 

11 

7 

19 

46 

BI-011 

13 

11 

26 

17 

46 

BI-009 

13 

11 

46 

12 

19 

Bl-OlO 

13 

12 

63 

18 

11 

BII-08 

13 

13 

2 

22 

16 

BII-13 

13 

16 

28 

20 

36 

811-12 

13 

16 

61 

22 

28 

BII-07 

13 

16 

37 

20 

27 

BI-008 

13 

16 

40 

22 

22 

BII-28 

16 

40 

23 

9 

BII-2b 

18 

22 

0 

64 

bII-09 

13 

18 

49 

0 

62 

BII-10 

13 

19 

46 

20 

31 

BII-27 

13 

20 

16 

2 

66 

BII-01 

13 

20 

26 

3 

0 

BII-13 

13 

20 

46 

2 

16 

BlI-04 

13 

21 

68 

7 

0 

BI-008 

13 

22 

22 

38 

BII-06 

13 

23 

8 

•: 

47 

BII-02 

14 

0 

22 

8 

69 

BII-29 

14 

0 

39 

7 

13 

BII-09 

14 

0 

62 

6 

33 

BI-009 

14 

3 

10 

11 

40 

BII-26 

14 

4 

49 

11 

36 

H-r, 

BII-14 

14 

4 

50 

8 

60 

BII-11 

14 

6 

14 

12 

66 

BII-03 

14 

6 

32 

13 

6 

Bl-OlO 

14 

7 

16 

14 

2 

BII-14 

14 

8 

60 

16 

29 

BII-02 

14 

8 

59 

9 

63 

BII-07 

14 

9 

48 

16 

33 

BII-05 

14 

9 

69 

19 

17 

BII-30 

14 

10 

17 

16 

67 

BII-10 

14 

11 

3 

19 

42 

BI-011 

14 

11 

22 

17 

42 

Bi-ooe 

14 

11 

40 

12 

IS 

Bl-OlO 

14 

12 

49 

18 

7 

DII-08 

14 

12 

67 

22 

12 

BII-13 

14 

16 

24 

2C 

32 

BII-12 

14 

16 

46 

22 

23 

BII-07 

14 
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17 
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29 
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17 
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3 

13 
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13 
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20 

26 

1 

40 

BII-30 

9 

21 

7 

4 

34 

BII-10 

9 

22 

46 

4 

66 
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i;li-07 

9 

22 

49 

8 

6 

MI-08 

10 

0 

23 

4 

67 

Bi-on 

10 

0 

66 

6 

47 

BII-06 

10 

1 

21 

8 

16 

BII-12 

10 

3 

14 

9 

48 

BII-13 

10 

4 

27 

13 

44 

Bl-OlO 

10 

4 

32 

6 

46 
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10 

4 

66 

9 

33 
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10 

4 

67 

11 

11 

BII-26 

10 

6 

2 

12 

27 

BI-008 

10 

6 

37 

10 

69 

BII-28 

10 

5 

41 

13 

30 

BII-07 

10 

7 

31 

8 

6 

BII-27 

10 

7 

43 

14 

8 

BII-09 

10 

7 

46 

17 

1 

BII-01 

10 

6 

28 

17 

16 

BII-04 

10 

9 

36 

13 

0 

BI-008 

10 

0 

66 

16 

17 

BII-02 

10 

12 

2 

16 

40 

Bii-oe 

10 

12 

20 

19 

8 

BII-04 

10 

13 

0 

20 

6 

BII-29 

10 

13 

38 

22 

3 

BI-009 

10 

14 

47 

22 

46 

BII-09 

10 

16 

26 

17 

12 

BII-02 

10 

16 

49 

22 

60 

BII-11 

10 

16 

49 

23 

17 

BII-03 

10 

17 

10 

0 

38 

BII-2B 

10 

17 

49 

2 

26 

BII-14 

10 

17 

66 

3 

9 

Bl-OlO 

10 

20 

9 

4 

28 

61-000 

10 

20 

20 

1 

36 

BII-30 

10 

21 

3 

4 

30 

BII-06 

10 

21 

36 

1 

17 

BII-10 

10 

22 

42 

4 

61 

BII-07 

10 

22 

44 

7 

27 

BIl-08 

11 

0 

19 

4 

53 

BI-Cll 

11 

0 

62 

6 

43 

BII-06 

11 

1 

17 

8 

12 

BII-12 

11 

3 

10 

8 

44 

BII-13 

11 

4 

23 

13 

4 

Bl-OlO 

11 

4 

28 

6 

42 

BII-10 

11 

4 

61 

9 

29 

BII-08 

11 

4 

63 

11 

7 

BII-26 

11 

4 

68 

12 

23 

BI-008 

11 

6 

33 

9 

62 

BII-28 

11 

6 

37 

13 

26 

BII-07 

11 

7 

27 

8 

1 

BII-27 

11 

7 

39 

14 

4 

BII-09 

11 

7 

42 

16 

21 

BII-01 

11 

9 

24 

17 

12 

BII-04 

11 

9 

31 

12 

66 

BH 


BI-008 

11 

9 

62 

16 

13 

BII-02 

11 

11 

67 

16 

46 

BII-06 

11 

12 

16 

19 

4 

BII-04 

11 

12 

66 

20 

2 

BII-29 

11 

13 

33 

21 

69 

BI-OOB 

11 

14 

43 

22 

41 

BII-09 

11 

16 

21 

17 

8 

BII-02 

11 

16 

46 

22 

46 

BII-11 

11 

16 

46 

23 

13 

BII-03 

11 

17 

6 

0 

34 

BII-2B 

11 

17 

46 

2 

21 

BII-14 

11 

17 

61 

3 

5 

Bl-OlO 

11 

20 

6 

4 

24 

BI-009 

11 

20 

16 

1 

31 

BII-30 

11 

20 

69 

4 

26 

BII-06 

11 

21 

31 

1 

13 

BII-10 

11 

22 

38 

4 

47 

BII-07 

11 

22 

40 

7 

23 

BII-08 

12 

0 

14 

4 

49 

BI-011 

12 

0 

48 

6 

39 

BII-06 

12 

1 

13 

8 

8 

BII-12 

12 

3 

6 

9 

40 

BII-13 

12 

4 

18 

13 

0 

Bl-OlO 

12 

4 

24 

6 

38 

BII-10 

12 

4 

47 

9 

25 

BII-08 

12 

4 

40 

11 

3 

BII-26 

12 

4 

64 

12 

19 

BI-008 

12 

6 

29 

9 

40 

611-28 

12 

6 

33 

13 

22 

BII-07 

12 

7 

23 

7 

66 

BII-27 

12 

7 

36 

14 

0 

BII-09 

12 

7 

38 

16 

17 

BII-01 

12 

9 

20 

17 

9 

BII-04 

12 

9 

27 

12 

61 

BI-008 

12 

9 

48 

16 

9 

BII-02 

12 

11 

63 

16 

40 

BII-06 

12 

12 

12 

19 

0 

BII-04 

12 

12 

61 

19 

68 

BII-2B 

12 

13 

29 

21 

66 

BI-009 

12 

14 

39 

22 

37 

BII-09 

12 

16 

17 

17 

4 

BII-02 

12 

16 

40 

22 

42 

BII-11 

12 

16 

41 

23 

8 

BII-03 

12 

17 

2 

0 

30 

BII-26 

12 

17 

41 

2 

17 

BII-14 

12 

17 

47 

3 

1 

Bl-OlO 

12 

20 

1 

4 

20 

BI-009 

12 

20 

12 

1 

27 

BlI-30 

12 

20 

66 

4 

21 

BII-06 

12 

21 

27 

1 

9 

BII-10 

12 

22 

34 

4 

43 

B-15 


BII-07 

12 

22 

36 

7 

19 

BII-08 

13 

0 

10 

4 

46 

BI-011 

13 

0 

44 

6 

36 
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13 

1 

9 

8 

4 

BII-12 

13 

3 

1 

9 

36 

BII-13 

13 

4 

14 

12 

66 
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4 

20 

5 

34 
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4 

43 

9 

21 
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4 

46 

10 

69 
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4 

49 

12 

16 

BI-008 

13 

5 

26 

9 
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5 

28 

13 

18 
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7 

19 

7 

62 
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13 

7 

31 

13 

66 
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13 

7 

34 

16 

13 
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13 

9 

16 

17 

6 

BII-04 

13 

S 

23 

12 

47 

BI-008 

13 

9 

44 

IS 

6 

BII-02 

13 

11 

49 

16 

36 

BII-06 

13 

12 

8 

18 

66 

BII-04 

13 

12 

47 

19 

63 

BII-29 

13 

13 

26 

21 

61 

BI-009 

13 

14 

36 

22 

33 

BII-09 

13 

16 

13 

17 

0 

BII-02 

13 

16 

36 

22 

38 

BII-11 

13 

16 

37 

23 

4 

BII-03 

13 

16 

68 

0 

26 

BII-26 

13 

17 

36 

2 

13 

BIl-i4 

13 

17 

43 

2 

66 

Bl-OlO 

13 

19 

67 

4 

16 

BI-009 

13 

20 

8 

1 

23 

BII-30 

13 

20 

60 

4 

17 

BII-OS 

13 

21 

23 

1 

6 

BII-10 

13 

22 

30 

4 

39 

BII-07 

13 

22 

32 

7 

16 

BII-08 

14 

0 

6 

4 

41 

BI-011 

14 

0 

40 

6 

31 

BII-OB 

14 

1 

6 

8 

0 

BII-12 

14 

2 

67 

9 

32 

BII-13 

14 

4 

10 

12 

62 

Bl-OlO 

14 

4 

16 

6 

30 

BII-10 

14 

4 

39 

9 

17 

BII-08 

14 

4 

41 

10 

66 

BII-2e 

14 

4 

46 

12 

11 

BI-OO0 

14 

6 

21 

9 

40 

BIl-28 

14 

5 

24 

13 

14 

BII-07 

14 

7 

16 

7 

48 

BII-27 

14 

7 

27 

13 

62 

BII-09 

14 

7 

30 

16 

9 

BII-01 

14 

9 

12 

17 

1 

BII-04 

14 

9 

19 

12 

43 

B-16 


BI-008 

14 

9 

40 

16 

1 

BII-02 

14 

11 

46 

16 

32 

BII-06 

14 

12 

4 

18 

62 

BII-04 

14 

12 

43 

19 

49 

BIl-29 

14 

13 

21 

21 

46 

BI-009 

14 

14 

30 

22 

29 

BII-09 

14 

16 

9 

16 

66 

BII-02 

14 

16 

32 

22 

34 

BII-11 

14 

16 

33 

23 

0 

BII-03 

14 

16 

64 

0 

22 

BIl-26 

14 

17 

32 

2 

9 

BII-14 

14 

17 

38 

r\ 

62 

Bl-OlO 

14 

19 

63 

4 

12 

BI-009 

14 

20 

4 

1 

19 

BII-30 

14 

20 

46 

4 

13 

BII-06 

14 

21 

19 

1 

1 

BII-10 

14 

22 

26 

4 

36 

BII-07 
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14 

22 

28 

7 

10 

BII-04 

9 

17 

4 

0 

16 

BII-02 

9 

19 

37 

3 

1 

BII-09 

9 

21 

8 

1 

7 

BII-14 

9 

21 

43 

1 

17 

BII-26 

9 

22 

4 

3 

34 

BI-009 

0 

22 

36 

6 

39 

BII-30 

9 

23 

10 

1 

26 

Bl-OlO 

10 

0 

16 

6 

11 

BII-01 

10 

0 

41 

2 

60 

BII-11 

10 

0 

47 

7 

38 

BII-03 

10 

2 

49 

8 

30 

BII-07 

10 

2 

69 

8 

6 

BI-011 

10 

4 

18 

10 

39 

BII-29 

10 

4 

33 

6 

69 

BII-06 

10 

6 

12 

12 

22 

BII-14 
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6 

48 

10 

66 

BII-10 
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0 

26 

13 

46 

BII-30 
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6 

38 

12 

18 

BII-26 
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BII-08 
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69 
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34 
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11 

66 

16 
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13 

34 

19 

17 

BII-26 
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14 
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20 
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60 
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19 
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10 
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BII-13 
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BI-Oll 
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17 
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18 

19 

BII-29 
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17 

42 

23 

23 

BI-008 
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18 

33 

23 

6 
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36 
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2 

66 

BII-28 

10 

20 

48 

22 
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10 
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BII-14 
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21 

39 

1 

13 

BII-26 
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22 
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BI-009 
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31 
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36 
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1 
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13 

41 
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BII-26 

11 

6 

69 

9 

21 
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11 

7 

66 

16 

12 
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11 

8 

29 

11 

9 

BII-13 

11 

8 

31 

12 

47 

BII-28 

11 

9 

37 

16 

26 

BI-008 

11 

9 

42 

13 

63 

Bl-OlO 

11 

9 

48 

13 

31 

BII-12 

11 

11 

30 

17 

44 

BII-09 

11 

11 

62 

16 

36 

BII-07 

11 

12 

37 

16 

3 

BII-01 

11 

13 

30 

19 

13 

BII-26 

11 

14 

32 

20 

9 

BII-27 

11 

15 

46 

22 

14 

BII-06 

11 

16 

11 

22 

21 

BII-04 

11 

16 

63 

0 

8 

BII-13 

11 

17 

8 

21 

38 

BI-011 

11 

17 

11 

18 

16 

BII-29 

11 

17 

37 

23 

19 

BI-008 

11 

18 

29 

23 

2 

BII-03 

11 

19 

11 

21 

31 

BII-02 

11 

19 

28 

2 

62 

BII-28 

11 

20 

44 

22 

61 

BII-09 

11 

21 

0 

0 

69 

BII-14 

11 

21 

36 

1 

9 

BII-26 

11 

21 

66 

3 

25 

BI-009 

11 

22 

27 

6 

31 

B-18 

,1-30 

11 

23 

2 

1 

17 

Bl-OlO 

12 

0 

8 

6 

2 

BII-01 

12 

0 

12 

2 

42 

BII-11 

12 

0 

38 

7 

30 

BII-03 

12 

2 

41 

8 

22 

BII-07 

12 

2 

61 

7 

67 

BI-011 

12 

4 

10 

10 

31 

BII-29 

12 

4 

26 

6 

61 

BII-06 

12 

6 

4 

12 

14 

BII-14 

12 

6 

39 

10 

46 

BII-10 

12 

6 

17 

13 

37 

BlI-30 

12 

6 

30 

12 

10 

BII-26 

12 

6 

66 

9 

17 

BII-08 

12 

7 

61 

16 

8 

BII-26 

12 

8 

26 

11 

6 

BII-13 

12 

8 

26 

12 

43 

BII-28 

12 

9 

33 

16 

22 

BI-008 

12 

9 

37 

13 

49 

Bl-OlO 

12 

9 

44 

13 

27 

BII-12 

12 

11 

26 

17 

40 

BII-09 

12 

11 

48 

16 

32 

Bri-07 

12 

12 

33 

15 

£9 

BII-01 

12 

13 

26 

19 

9 

BII-26 

12 

14 

27 

20 

£ 

BII-27 

12 

IS 

41 

22 

10 

BII-06 

12 

16 

7 

22 

17 

BII-  04 

12 

16 

61 

0 

4 

BII-  13 

12 

17 

4 

21 

34 

01-011 

12 

17 

7 

18 

11 

BII-20 

12 

17 

33 

23 

16 

BI-008 

12 

18 

26 

22 

68 

BII-03 

12 

19 

7 

21 

27 

BII- 02 

12 

19 

24 

2 

48 

BII-28 

12 

20 

40 

22 

46 

BII-09 

12 

20 

66 

0 

66 

BII-14 

12 

21 

31 

1 

6 

BII-26 

12 

21 

61 

3 

21 

BI-009 

12 

22 

23 

6 

27 

BII-30 

12 

22 

68 

1 

13 

Bl-OlO 

13 

0 

4 

4 

68 

BII-01 

13 

0 

28 

2 

3b 

BII-11 

13 

0 

34 

7 

26 

BII-03 

13 

2 

37 

8 

18 

BII-07 

13 

2 

47 

7 

S3 

BI-Oll 

13 

4 

6 

10 

27 

BII-29 

13 

4 

21 

6 

47 

BIl-06 

1 

6 

0 

12 

10 

EII-14 

13 

6 

36 

10 

42 

BII-10 

13 

0 

12 

13 

33 

DII-30 

13 

6 

26 

12 

6 

BII-26 

13 

6 

60 

9 

13 

\.  m 


BII-04 

14 

16 

43 

23 

66 

BII-13 

14 

16 

S6 

21 

26 

BI-011 

14 

16 

69 

18 

2 

BII-29 

14 

17 

26 

23 

7 

BI-008 

14 

18 

17 

22 

60 

BII-03 

14 

18 

69 

21 

19 

BII-02 

14 

19 

16 

2 

40 

BII-28 

14 

20 

32 

22 

38 

BII-09 

14 

20 

48 

0 

47 

BII-14 

14 

21 

23 

0 

67 

BII-26 

14 

21 

43 

3 

13 

BI-009 

14 

22 

16 

6 

10 

BII-30 

14 

22 

60 

1 

6 

Bl-OlO 

14 

23 

66 

4 

0 

BHD  0  0  C  0  0 


ti.5  Simulahon  Time  and  Parameters. 

This  short  data  file  is  pointed  to  by  the  value  in  the  T1ME.DAT  variable  and  contains  the 
simulation  start  and  end  times  and  three  simulation  parameters. 


100  00  00 
102  00  00 
3 
3 

10 


JJ.6  Ground  Antenna  Outage  Data. 

Thi  data  file  is  pointed  to  'oy  the  value  in  the  OUTAGE.DAT  variable  and  contains  textual 
.abci...  (hen  a  list  of  GA  index  numbers  and  outage  time  data.  T  he  simulation  will  not  have  the 
GAs  listed  available  for  use  during  the  periods  described.  A  text  description  of  the-  reason  for  the 
outage  is  also  provided 


"ASCI  out  lor  «ntir«  simulation. 
"DIEG  out  lor  entire  eimulation. 
2 

1  144000  2880  OUTAGb: 

3  144000  2880  OUTAGE 


It  21 


B.  7  Preliminary  Activity  Data. 


To  schedule  activities  immediately  at  the  start  of  the  simulation,  the  MCS  Simulation  program 
requires  information  on  the  activities  that  occured  just  prior  to  the  start  time.  The  file  pointed  to 
by  the  variable  ACT. DAT  contains  this  data.  The  ^le  below  contains  the  activities  for  all  24  test 


SVs. 


24 

93 


BI-008 

1 

ADDKEYS 

143816 

10 

1 

1 

4320 

BI-008 

1 

MAV 

143232 

6 

1 

1 

1440 

Bl-008 

1 

SOH 

143806 

10 

1 

1 

480 

Bi-009 

1 

ADDKEYS 

142703 

10 

1 

1 

4320 

BI-009 

1 

lAV 

142713 

6 

1 

1 

1440 

BI-009 

1 

SOH 

143738 

10 

1 

1 

480 

Bl-OlO 

1 

ADDKEYS 

143783 

10 

1 

1 

4320 

Bl-OlO 

1 

HAV 

142800 

5 

1 

1 

1440 

Bl-OlO 

1 

SOB 

143773 

10 

1 

1 

480 

BI-011 

1 

ADDKEYS 

143408 

1C 

< 

1 

4320 

BI-Oll 

1 

MAV 

142976 

6 

1 

1 

1440 

BI-Oll 

1 

SOH 

143922 

10 

1 

1 

480 

BII-01 

2 

GBDDUMP 

143608 

10 

1 

1 

720 

BlI-Ol 

2 

lAV 

143618 

16 

1 

1 

1440 

flII-01 

2 

HAVBUFF 

142808 

6 

1 

1 

1440 

BII-01 

2 

SOB 

143498 

10 

1 

1 

720 

BII-02 

2 

GBDDUMP 

143863 

10 

1 

1 

720 

BII-02 

2 

lAV 

143873 

16 

1 

1 

1440 

BII-02 

2 

lAVBUFF 

143302 

6 

1 

1 

1440 

BII-02 

2 

SOI 

143863 

It/ 

1 

1 

720 

BJ.I-03 

2 

GBDDUMP 

143841 

10 

1 

1 

720 

BII-  v'' 

2 

MAV 

143861 

16 

1 

1 

1440 

BII-03 

2 

■AVBUFF 

143C90 

6 

1 

1 

1440 

BII-03 

2 

SOH 

143831 

10 

1 

1 

720 

BII-04 

2 

GBDDUMP 

143770 

10 

1 

1 

720 

BII-04 

2 

MAV 

143780 

16 

1 

1 

1440 

BIX-04 

2 

MAVBJFF 

142926 

6 

1 

1 

1440 

BII-04 

2 

SOH 

143760 

10 

1 

1 

720 

BII-06 

2 

GBDDUMP 

143900 

10 

1 

1 

720 

BII -OS 

2 

lAV 

143076 

16 

1 

1 

144C 

BII-OB 

2 

VAVBUFF 

143910 

6 

1 

1 

1440 

BII-06 

2 

SOH 

143800 

10 

1 

1 

720 

Bir-06 

2 

GBDDUMP 

143637 

10 

1 

1 

720 

BII-00 

2 

MAV 

143647 

16 

1 

1 

1440 

BII-06 

2 

MAVBUFF 

142891 

6 

1 

1 

1*40 

BII-06 

2 

SOB 

143627 

10 

1 

1 

720 

BII-07 

2 

GBDDUMP 

143676 

10 

1 

1 

720 

u-n 


BII-07  2 

lAV 

142018 

16 

1 

1 

1440 

BII-07  2 

MAVBUFF 

143B86 

6 

1 

1 

1440 

BII-07  2 

SOB 

143666 

10 

1 

1 

720 

BII-08  2 

6BDDUMP 

143837 

10 

1 

1 

720 

BII-08  2 

lAV 

143243 

16 

1 

1 

1440 

BII-08  2 

lAVBUFF 

143847 

6 

1 

1 

1440 

BII-08  2 

SOB 

143827 

10 

1 

1 

720 

BII-09  2 

GBDDUNP 

143477 

10 

1 

1 

720 

BII-00  2 

lAV 

143487 

16 

1 

1 

1440 

BII-09  2 

■AVBUFF 

142836 

6 

1 

1 

1440 

BII-09  2 

SOB 

143467 

10 

1 

1 

720 

BII-10  3 

GBDDUMP 

143898 

10 

1 

1 

720 

BII-10  3 

MAY 

143126 

20 

1 

1 

1440 

BII-10  3 

lAVBUFF 

143008 

6 

1 

1 

1440 

BII-10  3 

SOLAR 

143878 

15 

1 

1 

360 

BII-10  3 

SOB 

143888 

10 

1 

1 

720 

BII-11  3 

GBDDUNP 

143466 

10 

1 

1 

720 

BII-11  3 

MAY 

142831 

20 

1 

1 

1440 

BlI-11  3 

lAVBUFF 

143466 

6 

1 

1 

1440 

BII-11  3 

SOB 

143446 

10 

1 

1 

720 

BII-:2  3 

IDUTLK 

143206 

10 

1 

1 

720 

BII-12  3 

MAY 

143300 

20 

1 

1 

1440 

BII-12  3 

lAVBUFF 

142742 

6 

1 

1 

1440 

BII-12  3 

SOB 

143280 

10 

1 

1 

720 

BII-13  3 

GBDDUNP 

143980 

10 

1 

1 

720 

BII-13  3 

lAV 

143260 

20 

1 

1 

1440 

BII-13  3 

lAVBUFF 

143900 

6 

1 

1 

1440 

BII-13  3 

SOB 

143970 

10 

1 

1 

720 

BII-14  3 

GBDDUNP 

143400 

10 

1 

1 

720 

BII-H  3 

lAV 

142700 

20 

1 

1 

1440 

BII-14  3 

lAVBUFF 

143410 

6 

1 

1 

1440 

BII-14  3 

SOB 

143390 

10 

1 

1 

720 

BII-26  3 

GBDDUNP 

143660 

10 

1 

1 

720 

BII-26  3 

lAV 

143660 

20 

1 

1 

1440 

BII-26  3 

lAVBUFF 

142960 

6 

1 

1 

1440 

BII-26  3 

SOB 

143640 

10 

1 

1 

720 

BII-26  3 

GBDDUNP 

143020 

10 

1 

1 

720 

BII-26  3 

■AV 

143160 

20 

1 

1 

1440 

BII-26  3 

lAVBUFF 

142030 

6 

1 

1 

1440 

BII-26  3 

SOB 

143910 

10 

1 

1 

720 

BII-27  3 

GBDDUNP 

143360 

10 

1 

1 

720 

BII-27  3 

lAV 

142640 

20 

1 

1 

1440 

BII-17  ? 

lAVBUFF 

143360 

6 

1 

1 

1440 

bII-27  3 

SOB 

1.43340 

10 

1 

1 

720 

BII'23  3 

GBDDUNP 

143010 

10 

1 

1 

720 

BII-28  3 

lAV 

143920 

20 

1 

1 

1440 

BII-28  3 

lAVBUFF 

143310 

6 

1 

1 

1440 

BII-28  3 

SOU 

143900 

10 

1 

1 

720 

BII-29  3 

GBDDUNP 

143816 

10 

1 

1 

720 

BII-29  3 

lAV 

143826 

20 

1 

1 

1440 

BII-2B  3 

lAVBUFF 

143120 

6 

1 

1 

1440 

H  23 


BII-29  3  SOH  14380B  10  1  1  720 
BII-oO  3  GBDDUMP  143440  10  1  1  720 
BII-30  3  lAV  142776  20  1  1  1440 
BII-30  3  lAVBUFF  143460  5  1  1  1440 
BII-30  3  SOH  143430  10  1  1  720 
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Appendix  C.  MCS  Simulation  Validation  Data/Results 


C.l  Validation  Ac<it)i<y  Data. 


Following  is  the  data  used  in  the  validation  of  the  MCS  Simulation.  These  data  describe  57 


actual  activities  that  were  scheduled  at  the  MCS  on  JlOO  (10  Apr)  1992.  The  data  were  used  to 
compare  the  scheduling  performance  of  the  simulation  to  the  schedule  created  at  the  MCS.  The 
format  is  identical  to  the  format  of  the  data  in  ACT. FILE,  except  that  the  GA  at  which  the  activity 


was  historically  scheduled  is  appended. 
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BI-008  1 

lAV 

144660 

6 

1 

1 

1440  CAPE 

BI-008  1 

SOB 

144200 

10 

1 

1 

480  DIEG 

BI-009  1 

lAV 

144146 

6 

1 

1 

1440  CAPE 

BI>000  1 

SOB 

144136 

10 

1 

1 

480  CAPE 

Bl-OlO  1 

lAV 

144236 

6 

1 

1 

1440  KVAJ 

Bl-OlO  1 

SOB 

144226 

10 

1 

1 

480  xua: 

BI-Oll  1 

lAV 

144386 

6 

1 

1 

1440  PIKE 

BI-011  1 

SOB 

144376 

10 

1 

1 

480  PIKE 

BII-01  2 

GBDDUNP 

144220 

10 

1 

1 

720  DIEG 

BII-01  2 

lAV 

144950 

16 

1 

1 

1440  KWAJ 

BIl-01  2 

■AVBUFF 

144230 

5 

1 

1 

1440  DIEG 

BII-01  2 

SOB 

144210 

10 

1 

1 

720  DIEG 

BII-02  2 

GBDDUMP 

144730 

10 

1 

1 

720  DIEG 

BII-02  2 

lAV 

145310 

16 

1 

1 

1440  KVAJ 

Bll-02  2 

■AVBUFF 

144740 

6 

1 

1 

1440  DIEG 

BII-02  2 

SOB 

144720 

10 

1 

1 

720  DIEG 

BII-03  2 

GBDDUMP 

144620 

10 

1 

1 

720  CAPE 

BII-03  2 

■AV 

146280 

16 

1 

1 

1440  PIKE 

BII-03  2 

■AVBUFF 

144630 

E 

1 

1 

1440  CAPE 

BII-03  2 

SOB 

144610 

10 

4 

1 

720  CAPE 

BII-04  2 

GBDDUNP 

144366 

10 

1 

1 

720  DIEG 

BII-04  2 

■AV 

146115 

15 

1 

1 

1440  KVAJ 

BII-04  2 

■AVBUFF 

144366 

6 

1 

1 

1440  DIEG 

BII-04  2 

SOB 

144346 

10 

1 

1 

720  DIEG 

BII-06  2 

GBDDUMP 

144606 

10 

1 

1 

720  PIKE 

BII-OB  2 

■AV 

144616 

16 

1 

< 

1440  PIKE 

BII-05  2 

■AVBUFF 

146340 

6 

1 

1 

1440  KVAJ 

BIl-06  2 

SOB 

144406 

10 

1 

1 

720  PIKE 

BII-06  2 

GBDDUMP 

144310 

10 

1 

1 

720  ASCi 

BII-06  2 

■AV 

146070 

16 

1 

1 

1440  KVAJ 

BII-06  2 

■AVBUFF 

144320 

6 

1 

1 

1440  ASCB 

BII-06  2 

SOB 

1300 

10 

1 

1 

720  ASCI 

Cl 


BII-07 

2 

GBDDUMP 

144360 

10 

1 

1 

720 

PIKE 

BII-07 

2 

ViV 

144360 

16 

1 

1 

1440 

PIKE 

BII-07 

2 

lAVBUFF 

146026 

6 

1 

1 

1440 

DIBG 

BII-07 

2 

SOH 

144340 

10 

1 

1 

720 

PIKE 

BII-08 

2 

GBDDimP 

144666 

10 

1 

1 

720 

PIKE 

BII-08 

2 

RAV 

144666 

16 

1 

1 

1440 

PIKE 

BII-08 

2 

HAVBUFF 

146280 

6 

1 

1 

1440 

DIEG 

BII-08 

2 

SOH 

144646 

10 

1 

1 

720 

PIKE 

BIl-09 

2 

GBDDUKP 

144260 

10 

1 

1 

720 

ASCR 

BIl-09 

2 

RAV 

144906 

16 

1 

1 

1440 

KWAJ 

BII-09 

2 

RAVBUFF 

144270 

6 

1 

1 

1440 

ASCR 

BII-09 

2 

SOH 

144260 

10 

1 

1 

720 

ASCR 

BIl-10 

3 

GBDDUMP 

144660 

10 

1 

1 

720 

PIKE 

BII-10 

3 

RAV 

144660 

20 

1 

1 

1440 

PIKE 

BII-10 

3 

RAVBUFF 

146310 

6 

1 

1 

1440 

DIEG 

BII-10 

3 

SOLAR 

144240 

16 

1 

1 

360 

KUAJ 

BII-10 

3 

SOB 

144640 

10 

1 

1 

720 

PIKE 

Bii-n 

3 

GBDDUMP 

144266 

10 

1 

1 

720 

CAPE 

BII-11 

3 

RAV 

144276 

20 

1 

1 

1440 

CAPE 

BII-11 

3 

RAVBUFF 

144905 

6 

1 

1 

1440 

DIEG 

BIl-11 

3 

SOH 

144266 

10 

1 

1 

V20 

CAPE 

BII-12 

3 

RDUTLM 

144176 

10 

1 

1 

720 

DIEG 

BII-12 

3 

RAV 

144740 

20 

1 

1 

1440 

CAPE 

BII-12 

3 

RAVBUFF 

144186 

6 

1 

1 

1440 

DIEG 

BII-12 

3 

SOH 

144166 

10 

1 

1 

720 

DIEG 
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C.2  Validation  Results. 


There  were  14  validation  runs  made.  The  object  was  to  “tune”  the  simulation  parameters 
affecting  scheduling  to  maximize  the  correlation  between  a  set  of  MCS-schedulcd  activities  and  that 
same  set  of  activities  scheduled  by  the  simulation.  The  raw  results  of  these  runs  are  below. 


SCHBDULIIG  mPUTS 

TIME:  100/  0;  0  to  101/  0:  0  (144000  to  146440) 
16  SVs 
6  GAs 

3  Max  contacts 

Actual  GA  JlOO  Baint,  «/  jlOO  CPU  outage 
Pika  lull  availability 
VI  -  TBS  rank:  hP/hL/hl 


9  Praackadulad  outages: 


Index 

Start 

Durat  ion 

Cause 

1 

144000 

90 

CPU.OUT 

2 

144000 

90 

CPU.OUT 

3 

144000 

90 

CPU.OUT 

4 

144000 

90 

CPU.OUT 

6 

144000 

90 

CPU.OUT 

1 

144120 

120 

PKI 

3 

144420 

120 

PHI 

4 

144600 

120 

PHI 

2 

145080 

359 

LAUICH 

RESULTS: 

luaber 

Max 

Min 

Mean 

Std  Dev 

OFFSET: 

92 

90 

0 

1 . 9565 

13.1247 

PRIORITY: 

02 

3 

0 

0.0652 

0.4376 

GA  UTIL: 

1440 

3 

0 

0.7132 

0.7864 

GA  RESV: 

1440 

5 

0 

1.6313 

1.2396 

PRIORITY: 

Value 

lumber 

Percent 

0 

90 

97.83 

1 

0 

0. 

2 

0 

0. 

3 

2 

2.17 

4 

0 

0. 

6 

0 

0. 

6 

0 

0. 
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7 

0 

0. 

8 

0 

0. 

e 

0 

0. 

10 

0 

0. 

11 

0 

0. 

GA  UTILIZATIOI/k^lSERVATIOl : 

Valu* 

luabar 

Percent 

0 

678/  227 

47.08/  16.76 

1 

630/  632 

36.81/  43.86 

2 

109/  368 

13.82/  26.66 

3 

33/  106 

2.29/  7.36 

OFFSET: 

Value 

luaber  1 

Percent 

0 

90 

97.83 

10 

0 

0. 

20 

0 

0. 

30 

0 

0. 

40 

0 

0. 

60 

0 

0. 

60 

0 

0. 

70 

0 

0. 

80 

0 

0. 

60 

2 

2.17 

100 

0 

0. 

110 

0 

0. 

120 

0 

0. 

130 

0 

0. 

140 

0 

0. 

160 

0 

0. 

160 

0 

0. 

170 

0 

0. 

180 

0 

0. 

190 

0 

0. 

200 

0 

0. 

210 

0 

0. 

220 

0 

0. 

230 

0 

0. 

240 

0 

0. 

SCHEDULI 

IG  IIPUTS 

TIKE:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
16  SVs 
6  GA8 

3  Max  contact* 

Actual  GA  JlOO  saint,  «/  jlOO  CPU  outaga 
Pike  full  availability 
VI  -  TBS  rank;  hP/hL/hl 
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VALIDATIOI  RESULTS: 

■umber 

Max 

Min 

Mean 

Std  Dev 

START  OFTSET: 

S7 

148 

0 

41 . 1404 

40.9769 

GA  NATCH: 

23 

ACTIVITY  START  OFFSET: 
Value  lunber  Percent 


0 

36 

63.16 

SO 

16 

26.32 

100 

6 

10.63 

lEO 

0 

0. 

200 

0 

0. 

260 

0 

0. 

300 

0 

0. 

360 

0 

0. 

400 

0 

0. 

460 

0 

0. 
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SCHBOULIIG  IIPUTS 

TIME:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
16  SVb 
6  GAs 

3  Max  contacts 

Actual  GA  JlOO  maint,  «/  jlOO  CPU  outage 
Pike  lull  availability 
V2  -  TBS  rank:  hP/hL/lSV 


VALIDATIOI  RESULTS: 

lojnber 

Max 

Min 

Mean 

Std  Dev 

START  OFFSET: 

67 

148 

0 

41.1404 

40.9769 

GA  MATCH: 

23 

ACTIVITY  START  OFFSET: 
Value  lumber  Percent 


0 

36 

63.16 

60 

15 

26.32 

100 

6 

10.63 

150 

0 

0. 

200 

0 

0. 

250 

0 

0. 

300 

0 

0. 

380 

0 

0. 

400 

0 

0. 

460 

0 

0, 

SCBBDULIKC  IIPUTS 

TIME:  100/  0:  0  to  101/  0:  0  (144000  to  145440) 
10  SV8 
E  GAs 

3  Max  contacts 

Actual  GA  JlOO  maint,  «/  jlOO  CPU  outage 
Pika  full  availability 
V3  -  TBS  rank-  hP/lL/hl 


VALIDATIOM  RESULTS: 


lumber 

Max 

Min 

Mean 

START  OFFSET: 

87 

16  < 

0 

41 . 9828 

GA  MATCH: 

25 

ACTIVITY  START 

OFFSET; 

Value 

lumber 

Percent 

0 

37 

64.91 

80 

13 

22.81 

100 

6 

10.63 

180 

1 

1.76 

200 

0 

0. 

260 

0 

0. 

300 

0 

0. 

360 

0 

0. 

400 

0 

0. 

460 

0 

0. 

Std  Dav 

43.00B3 


C-7 


SCHBOULIIG  IHPUTS 

TIME:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
16  SVa 
6  GAa 

3  Max  contacta 

Actual  GA  JlOO  maint,  b/  jlOO  CPU  outage 
Pika  lull  availability 
V4  -  TBS  rank:  hP/lL/lSV 


VALIDATIOI  RESULTS: 


lumber 

Max 

Min 

Mean 

Std  Dev 

START  OFFSET: 

67 

168 

0 

41.9826 

43 . 0063 

GA  HATCH: 

26 

ACTIVITY  START  OFFSET: 


Value 

lumber 

Percent 

0 

37 

64.91 

60 

13 

22.81 

100 

6 

10.63 

160 

1 

1.76 

200 

0 

0. 

260 

0 

0. 

300 

0 

0 

360 

0 

0. 

400 

0 

0, 

450 

0 

0. 
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^HEDULIIG  IIPUTS 

TIME:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
16  SVs 
6  CAs 

3  Max  contacts 

Actual  GA  JlOO  aaint,  v/  jlOO  CPU  outaga 
Pika  lull  availability 
V6  -  TBS  rank:  hP/lSV/lL 


VALIDATIOI  RESULTS: 

lumbar 

Max 

Min 

Maan 

Std  Dev 

START  OFFSET: 

67 

148 

0 

40.8047 

41.0666 

GA  MATCH: 

26 

ACTIVITY  ST*'  •  OFFSET: 
Valu'  . isbar  Percent 


0 

37 

64.91 

60 

14 

24.68 

100 

6 

10.63 

160 

0 

0. 

200 

0 

0 

2o9 

0 

0. 

300 

0 

0. 

360 

0 

0. 

400 

0 

0. 

460 

0 

0. 
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SCHEDULIMG  IIPUTS 

TIHB:  100/  0:  0  to  101/  0:  0  (144000  to  145440) 
16  SVb 
6  G&b 

3  Max  contacts 

Actual  GA  JlOO  aaint,  v/  jlOO  CPU  outags 
Pika  full  availability 
V6  -  TBS  rank:  hP/lSV/hL 


VALIDATIOI  RESULTS; 


luabar 

Max 

Kin 

M«an 

Std  Dev 

START  OFFSET: 

67 

148 

0 

40.8947 

41.0666 

GA  NATCH: 

26 

ACTIVITY  START  OFFSET; 


Value 

lumber 

Percent 

0 

37 

64.61 

60 

14 

24.66 

100 

6 

10.63 

150 

0 

0. 

200 

0 

0. 

260 

0 

0. 

300 

0 

0. 

0 

0. 

400 

0 

0. 

460 

0 

0. 
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SCHBDULII6  IIPUTS 

TIME;  100/  0:  0  to  101/  0:  0  (144000  to  145440) 
16  SVa 
6  GAS 

3  Max  contacts 

Actual  GA  JlOO  naint.  h/  jlOO  CPU  outage 
Pike  lull  availability 
V7  -  TBS  rank:  hP/hl 


VALIDATIOI  RESULTS: 

luaber 

Max 

Min 

Mean 

Std  Dev 

START  OFFSET; 

57 

148 

0 

40.8246 

41.0648 

GA  MATCH; 

25 

ACTIVITY  START  OFFSET: 
Value  luaber  Percent 


0 

20 

35.09 

10 

7 

12.28 

20 

3 

6.26 

30 

3 

6.26 

40 

4 

7.02 

60 

2 

3.61 

60 

4 

7.02 

70 

1 

1.76 

80 

3 

6.26 

90 

4 

7.02 

100 

2 

3.61 

110 

2 

3.51 

120 

0 

0. 

130 

0 

0. 

140 

2 

3.61 

160 

0 

0. 

160 

0 

0. 

170 

0 

0. 

180 

0 

0. 

100 

0 

0. 

200 

0 

0. 

C-11 


h 


^CEBDULIIG  IIPUTS 

TINE;  100/  0:  0  to  101/  0:  0  (144000  to  14B440) 
16  SVb 
6  G&e 

3  Max  coQtacta 

Actual  GA  JlOO  aaint,  «/  jlOO  CPU  outaga 
Pike  full  availability 
V8  -  TBS  rank:  hP/lI 


VALIDATIOI  RESULTS: 

lonber  Max  Min  Moan 


START  OFFSET:  S7  148  0  40.&96S 

GA  MATCH:  26 


ACTIVITY  START  OFFSET: 


Value 

lonber 

Percent 

0 

20 

35.00 

10 

7 

12.28 

20 

3 

6.26 

30 

3 

6.26 

40 

4 

7.02 

60 

2 

3.61 

60 

8 

8.77 

70 

0 

0. 

80 

3 

6.26 

00 

4 

7.02 

100 

2 

3.61 

no 

2 

3.61 

120 

0 

0. 

130 

0 

0. 

140 

2 

3.61 

160 

0 

0. 

160 

0 

0. 

170 

0 

0. 

180 

0 

0. 

190 

0 

0. 

200 

0 

0. 

Std  Dev 

40.8356 
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SCHBDULIIQ  IIPDTS 

TIHE:  100/  0:  0  to  101/  0:  0  (144000  to  14&440) 
16  SVa 

6  GAa 

3  Nu  contacts 

Actnal  GA  JlOO  aalnt,  ■/  jlOO  CPU  outage 
Pike  lull  availability 
VIO  -  TBS  rank:  hP/lD 


VALIDATIOI  RESULTS: 

luaber 

Max 

Min 

Mean 

Std  Dev 

START  OFFSET;  67 

GA  MATCH:  26 

148 

0 

40.8246 

41.0648 

ACTIVITY  START  OFFSET: 


Value 

luaber 

Percent 

0 

20 

36.09 

10 

7 

12.28 

20 

3 

6.26 

30 

3 

6.26 

40 

4 

7.02 

60 

2 

3.61 

60 

4 

7.02 

70 

1 

1.76 

80 

3 

6.26 

90 

4 

7.02 

100 

2 

3.61 

110 

2 

3.61 

120 

0 

0. 

130 

0 

0. 

140 

2 

3.61 

160 

0 

0. 

160 

0 

0. 

170 

0 

0. 

180 

0 

0. 

190 

0 

0. 

200 

0 

0. 
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SCEEDULIir,  IIPUTS 

TINE:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
16  SVt 
5  GAs 

3  Nax  contacts 

Actual  OA  JlOO  ardnt.  «/  jlOO  CPU  outags 
Pika  full  availv:  jility 
Vll  -  TBS  rank:  hP/lI/hSV 


VALIOATIOI  RESULTS: 

luabsr 

Mm 

Min 

Nsan 

Std  Dsv 

START  OFFSET: 

67 

148 

0 

40.6667 

40.8276 

GA  NATCH: 

26 

ACTIVITY  START  OFFSET: 
Valus  ItUBbar  Psrcsnt 


0 

20 

36.09 

10 

7 

12.28 

20 

3 

6.26 

30 

3 

6.26 

40 

4 

7.02 

«0 

2 

3.61 

60 

6 

8.77 

70 

0 

0. 

80 

3 

6.26 

80 

4 

7.02 

100 

2 

3.61 

110 

2 

3.61 

120 

0 

0. 

130 

0 

0. 

140 

2 

3.61 

160 

0 

0. 

160 

0 

0. 

170 

0 

0. 

180 

0 

0. 

190 

0 

0. 

200 

0 

0. 
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SCHEDULIIG  IIPUTS 

TIKB:  100/  0:  0  to  101/  0:  0  (144000  to  14S440) 
1«  SVs 
6  Qka 

3  Nu  contacts 

Actual  GA  JlOO  aaint,  «/  jlOO  CPU  outags 
Pika  lull  availability 
V12  -  TBS  rank;  hP/lI/lSV 


VALIDATIOR  RESULTS; 

lumbar 

Max 

Min 

Naan 

START  OFFSET: 

67 

148 

0 

40 . E66E 

GA  MATCH; 

26 

ACTIVITY  START  OFFSET: 
Valua  Itwbar  Parcant 


0 

20 

36.09 

10 

7 

12.28 

20 

3 

6.26 

30 

3 

6.26 

40 

4 

7.02 

60 

2 

3. El 

60 

6 

8.77 

70 

0 

0. 

80 

3 

6.26 

SO 

4 

7.02 

100 

2 

3.61 

110 

2 

3.61 

120 

0 

0. 

130 

0 

0. 

140 

2 

3.61 

160 

0 

0. 

160 

0 

0. 

170 

0 

0. 

180 

0 

0. 

190 

0 

0. 

200 

0 

0. 

Std  Dav 

40.83B& 
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SCIEDULIIG  IIPUTS 

TIME:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
10  SVa 

6  Gia 

3  Max  contactn 

ictual  GA  JlOO  saint,  ■/  jlOO  CPU  outaKa 
Pika  full  availability 
V13  -  TBS  rank:  hP/lI/hST 


VALIDATIOI  RESULTS: 

Inabar  Max  Kin  Mean 


START  OFFSET:  67  148  0  41.1404 

GA  NATCH;  26 


ACTIVITY  START  OFFSET: 
Valna  Inaibar  Parcant 


0 

20 

36.09 

10 

7 

12.28 

20 

3 

5.26 

30 

2 

3.61 

40 

4 

7.02 

60 

2 

3.61 

60 

6 

10.63 

70 

0 

0. 

80 

3 

6.26 

00 

4 

7.02 

100 

2 

3.61 

liO 

2 

3.61 

120 

0 

0. 

130 

0 

0. 

140 

2 

3.61 

ISO 

0 

0. 

160 

C 

0. 

170 

0 

0. 

180 

0 

0. 

160 

0 

0. 

200 

0 

0. 

Std  Dev 

40.9769 
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SCRBDULIIG  IIPUTS 

TIHB:  100/  0:  0  to  101/  0:  0  (144000  to  146440) 
16  SVb 
5  GAb 

3  Max  contacts 

Actual  GA  JlOO  aalnt,  w/  jlOO  CPU  outag* 

Pika  lull  availability 
V14  -  TBS  rank;  hP/lI/lST 


VALIDATIOI  RESULTS; 

luaber 

Max 

Min 

Hsan 

Std  Dev 

START  OFFSET: 

67 

168 

0 

ti.4211 

42.6972 

GA  NATCH: 

26 

ACTIVITY  START  OFFSET: 


Value 

Btutber 

Percent 

0 

18 

31.68 

10 

9 

16.79 

20 

6 

8.77 

30 

3 

6.26 

40 

3 

6.26 

60 

1 

1.76 

60 

3 

6.26 

70 

2 

3.61 

80 

2 

3.61 

00 

4 

7.02 

100 

2 

3.61 

110 

3 

6.26 

120 

0 

0. 

130 

0 

0. 

140 

1 

1.76 

160 

0 

0. 

160 

1 

1.76 

170 

0 

0. 

180 

0 

0. 

190 

0 

0. 

200 

0 

0. 
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Appendix  D.  Visibility  Table  Generation. 

This  appendix  describes  the  process  used  to  generate  the  visibility  table  and  prepare  it  for 
use  with  the  MCS  simulation.  The  visibility  tables  used  in  the  MCS  simulation  were  generated 
using  an  external  program  -  Pass  Scheduler.  As  the  program  author,  Lt  Col  T.  S.  Kelso,  describes 
the  program  in  the  instruction  manual; 


Pass  Scheduler  is  a  program  which  will  allow  the  you  to  automatically  generate  schedules  of 
satellite  passes  from  a  set  of  pre-selected  files  of  observation  sites  and  NORAD  two-line  orbital 
element  sets  (6).  Pass  Scheduler  (henceforth  PS)  requires  three  type  of  data  to  generate  visibilities: 
1)  a  description  of  the  satellite  orbit;  2)  a  description  of  the  observer’s  position;  and  3)  the  viewing 
parameters.  Here  is  the  description  of  these  data  and  how  they  were  gathered 

D.0.1  Satelhie  Orbital  Data  PS  requires  satellite  data  be  in  the  form  of  a  North  American 
Air  Defense  Command  (NORAD)  two-line  orbital  element  set  (commonly  abbreviated  TLE).  NO¬ 
RAD  uses  this  format  to  distribute  satellite  orbital  data  on  the  space  objects  tracked  by  NORAD’o 
Space  Surveillamce  Center.  Among  other  details,  a  TLE  describes  the  satellite  orbit  in  terms  of 
its  Keplerian  elements.  Below  is  a  description  of  the  NORAD  TLE  format,  from  documentation 
provided  with  the  PS  manual. 

Data  lor  each  satellite  consists  of  three  lines  in  the  tollowing  lormat: 

kkkkkkkkkkk 

1  miiu  mnwiAu  +.ihiiiihx  ^biihh-h  >nmhri-n  n  hriiin 

2  IIIII  m.llil  III. III!  Illllll  mR.IBIR  IRI.NIIN  HH . IHNIHHHHHHHRHH 
Line  0  is  a  eleven-character  name. 

Linas  1  and  2  are  the  standard  Tso-Line  Orbital  Element  Set  Format 
identical  to  that  used  by  lORAD  and  lASA.  The  format  description  is: 

Line  1 


D-1 


Coluan  Datcrlption 

01-01  Lln«  lUBbar  of  Blaaant  Data 

03-07  Satallita  lumbar 

10-11  Intaraatloaal  Daalgnator  (Last  two  digits  ol  launch  paar) 

12-14  Intamatlonal  Daalgnator  (Launch  nuabar  of  tha  yaar) 

16-17  Intamatlonal  Daalgnator  (Place  of  launch) 

19-20  Epoch  Yaar  (Laat  two  dl^ita  of  yaar) 

21-32  Epoch  (Julian  Day  and  fractional  portion  of  tha  day) 

34-43  Flrat  Tiaa  Derivative  of  the  Kean  Motion 

or  Balllatic  Coefficient  (Dapandlng  on  aphanaris  type) 

46-62  Second  Tiaa  Derivative  of  Naan  Notion  (daciaal  point,  aasuaad; 
blank  if  I/A) 

64-61  BSTAR  drag  tana  if  GP4  general  perturbation  theory  was  used.  Otharwiaa, 
radiation  praasura  coefficient.  (Daciaal  point  assumed) 

63-63  Bphaaaris  type 
66-68  Element  number 
69-66  Check  Sum  (Modulo  10) 

(Letters,  blanks,  periods,  plus  signs  =  0;  minus  signs  =1) 


Line  2 

Column  Description 

01-01  Line  lumber  of  Element  Data 

03-07  Satellite  lumber 

09-16  Inclination  CDegrses] 

18-26  Right  Ascension  of  the  Ascending  Rode  CDegreea] 
27-33  Eccentricity  (decimal  point  assumed) 

36-42  Argument  of  Perigee  [Degrees] 

44-61  Mean  Anomaly  [Degrees] 

63- 63  Mesui  Notion  [Revs  per  day] 

64- 68  Revolution  number  at  epoch  [Revs] 

69-69  Check  Sum  (Modulo  10) 

All  other  columns  are  blank  or  fixed. 

(«) 


The  TLE  describes  the  orbit  at  a  single  instant  (the  epoch  of  the  TLE),  but  the  position  of  the 
satellite  at  other  times  can  be  determined  by  mathematically  “propagating”  the  epoch  trajectory 
forward  or  back  in  time. 


TLE’s  exist  for  all  the  GPS  satellites  now  operational  However,  the  simulation  required  TLEs 
for  GPS  satellites  not  yet  launched.  The  problem  was  solved  using  the  trajectories  of  the  existing 
satellites  and  the  fact  that  the  GPS  SVs  are  spaced  at  90  degree  intervals  in  the  six  orbital  planes 
(5:88).  The  trajectories  for  the  missing  satellites  were  estiniated  by  propagating  the  trajectories 
of  the  existing  satellites  to  a  common  epoch.  With  the  satellite’s  positions  fixed  at  a  common 
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time,  the  missing  orbital  “slots”  in  each  plane  becomes  apparent.  Assuming  the  newly  launched 
satellites  will  fill  these  holes,  element  sets  were  created  using  the  appropriate  elements  from  the 
existing  satellites  in  the  plane,  with  the  locations  of  the  slots  filling  in  the  unknown  quantities. 

Once  the  GPS  SV  TLEs  have  been  either  gathered  or  synthesized,  they  are  placed  in  a  file 
named  GPS.TLE  to  be  called  by  PS  at  the  appropriate  time.  The  TLE  file  used  to  generate  the 
visibility  is  as  follows: 


OP8-0010 

1  162711’  84  97  4  92729.07206774  -  00000014  00000-0  99999-4  0  3190 

2  16271  02.7700  300.3243  0124103  339.4139  20.1076  2.00682276  66963 
OPS  BII-12 

1  218900  92  9  4  92229.18326797  -  .00000014  00000-0  99999-4  0  1060 

a  21890  64.6839  284.3872  0060248  144.1409  219.3309  2.00694032  3484 

OPS  BTI-04 

1  2030211  89  86  4  92226.86446249  -.00000016  00000-0  99999-4  0  3997 
a  20302  64.0381  284.9837  0019026  327.9882  32.2974  2.00698403  2068Y 

OPS  Bn-07 

1  206330  90  26  4  92220. 07959671  -  .00000033  00000-0  99990-4  C  4013 

2  20633  66.2262  344.1490  0039438  82.2444  208.1777  2.00603763  17434 
OPS  BII-02 

1  3OO01U  09  44  4  92226.48398376  -.00000033  00000-0  99999-40  4668 

2  20081  64.8872  343.8391  0109792  194.7642  194.9389  2.00681894  23309 

OP8-0009 

1  16039U  64  69  4  92226.02982046  -.00000004  00000-0  99999-4  0  6316 
216039  03.6974  62.16670040962316.1410141.6399  3.0069880469864 
aP8  BII-13 

1  31930U  93  19  4  92336.89020167  -.00000019  00000-0  99999-40  1063 

2  21930  86.2040  44.6462  0076933  167.9638  202.4006  2.00667847  2406 

aps-ooos 

1141890  83  72  4  92229 .46326188  -  .00000004  00000-0  99999-4  0  2680 

2  14189  63.8084  93.1910  0139626  231.4399  127.4011  2.00663083  99675 

OP8-0011 

1  19129U  86  93  4  92229.79394990  -.00000003  00000-3  99999-4  0  207 

2  19129  64.3249  63.7939  0128101  143.0968  217.2869  2 .00666079  E0179 
QP8  BIl-11 

1  21662U  91  47  4  92226.22306376  .  00000009  00000-0  99999-4  0  2106 

2  71662  66  4011  104.6689  0042939  228.0711  134.6904  2.00673108  8113 

OPS  BII-09 

1  20830U  90  88  4  92226.64964393  .  00000007  00000-0  99999-4  0  3626 

2  20830  66.1038  107  1790  0070049  109.7801  261.0690  2 .006023e7  13B3S 

OPS  811-06 

1  20391U  89  97  4  92336.30914862  .  00000007  00000-0  99999-4  0  3633 

2  20301  66.1884  109  0600  0009698  83.3689  377.4966  3  00663334  10166 

OPS  BlI-01 

1  198031;  SO  13  4  93236.14763199  .  00000016  00000-0  99999-4  0  4609 

3  19902  66.0467  196.3474  0041381  173.7861  187.3444  2.00680023  26669 

OPS  BlI  08 

1  20724U  90  08  4  9232S  .99001477  .  00000016  OOCOO-0  99999-4  0  3046 

2  20724  64.9819  194.8310  0092634  131 .6392  228.9309  3.00666479  14842 

OPS  BlI-03 

1  aoiecu  89  64  4  92223.33198841  .UOOOOOIS  00000-0  99999-4  0  4014 

3  20186  64.8802  187.0704  0013047  198.9931  161.2346  2.00667084  31872 

OrS  BlI-10 

1  30960U  90103  4  02236.46418487  .00000016  00000-0  99999-4  0  2636 


n-3 


2  }0ft69  S4. 9117  IM. 0023  0062140  219. 071S  140. 44ai  2.00566067  12S04 
OPS  BII-14 

1  220140  92  39  1  92226.93117623  .  00000010  00000-0  99999-4  0  231 
r^3  22014  66.0433  224.6691  0083797  276.3627  83.6992  2.00670262  738 

OPS  BII-06 

1  204620  90  8  1  92226.77349666  .  00000009  00000-0  99999-4  0  4006 

2  20462  64.1863  223.6693  0044660  66.6406  294.8162  2.00662860  18661 


D.0.2  Observer  Position  Data.  The  positions  of  the  GPS  ground  stations,  especially  the 
Monitor  Stations,  have  been  determined  very  accurately.  The  positions  provided  to  PS  in  the  file 
GPS.OBS  were  taken  directly  from  a  GPS  Mission  Console  display  The  OBS  file  is  reproduced 
below. 


ItCl 

1 

07 

67 

04 

3 

014 

24 

43 

H 

lOS 

C4PB 

1 

28 

29 

02 

■ 

080 

34 

22 

U 

-18 

DtEO 

1 

07 

16 

12 

S 

072 

22 

IS 

E 

-63 

IklJ 

1 

08 

43 

23 

1 

167 

43 

62 

E 

41 

Pli.t 

1 

38 

48 

11 

1 

104 

31 

30 

U 

1913 

Each  line  describes  the  location  of  one  ground  station.  In  the  Pass  Scheduler  instructions. 


Kelso  describes  the  format  of  the  file  thus: 


Each  observer  file  must  have  an  extension  .OBS.  A  sample  observer  file  is  shown  below. 
Each  line  allows  20  ch3rcw:ter8  for  a  place  name,  a  time  zone  difference  (not  used),  and 
the  observation  site’s  latitude  (in  degrees,  minutes,  and  seconds  followed  by  N  or  S), 
longitude  (in  degrees,  minutes,  and  seconds  followed  by  W  or  E),  and  altitude  above 
mean  sea  level  (in  meters).  (6) 


D.0.3  Pass  Schedvle  Parameters.  The  remaining  information  required  by  PS  is  to  the  time 
difference  between  the  program  users’  time  and  Universal  Coordinated  Time  (commonly  referred 
to  ae  “Greenwich”  or  “ZULU”  time),  and  a  number  of  parameters  that  define  the  users’  input 
and  output  desires.  This  information  is  stored  in  a  file  called  “PASSCHED.CFG”,  which  is  shown 
below. 


-4  X  Tin*  dlff«r«nc*  froa  UTC 

I  X  Echo  satolllt*  dtto 
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T  X  Echo  ■chodolo  to  dlak  fil« 

I:  X  dtlfo  lor  topport  fllaa 

X  Dofanlt  dlroctorj  for  support  filss 
OPS. DBS  X  Dofaolt  obssrosr  databua 

nVOPS.TLE  X  Dofanlt  aatalllta  databasa 

During  program  execution,  the  user  is  prompted  to  enter  the  desired  visibility  time  interval, 
the  satellite  elevation  (from  the  ground  station  local  horizon)  at  which  the  satellite  is  declared  risen 
or  set,  and  the  minimum  duration  visibility  period  the  user  wishes  to  have  reported. 

D.0.4  Pass  Schedule  Output.  In  the  raw  Pass  Scheduler  output,  the  name  and  location  of 
the  ground  stations  for  which  the  following  satellite  observations  apply  is  listed  first,  along  with 
the  user-defined  parameters.  Then  each  satellite  is  listed  in  the  order  in  which  they  rise  at  that 
station.  The  times  (under  “Rise”,  ‘ToC”,and  “Set”)  are  in  hour/minute/second  format.  “Az”  and 
“El”  are  satellite  azimuth  and  elevation,  respectively.  ToC  is  time  of  culmination,  the  instant  of 
maximum  elevation  for  that  satellite  '  iaibility  period.  The  last  column  contains  codes  for  classifying 
the  visibility  period. 

To  convert  this  format  to  the  one  needed  for  the  MCS  Simulation  program,  the  raw  PS  output 
was  imported  to  a  computer  spreadsheet,  the  data  formed  into  columns,  and  the  extraneous  data 
removed.  The  long  ground  station  header  was  replaced  with  just  the  name  and  index  number  of 
the  GA. 
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Abstract 

The  United  States  Ait  Force’s  Navstat  Global  Positioning  System  (GPS)  provides  high-accuracy  space- 
based  navigation  and  time  distribution  to  suitably-equipped  military  and  civilian  users.  The  system  consists 
of  earth-orbiting  satellites  and  a  world-wide  network  of  ground  stations.  A  single  operational  control  center, 
the  GPS  Master  Control  Station  (MCS)  monitors,  maintains,  and  commands  the  GPS  satellite  constellation. 
The  on-going  deployment  of  the  complete  satellite  constellation  and  recent  changes  in  the  operational  crew 
structnre  may  invalidate  previously  used  planning  and  management  paradigms.  There  is  currently  no  an¬ 
alytical  method  for  predicting  the  impact  of  these  and  other  environmental  changes  on  system  parameters 
and  performance.  Extensive  testing  cannot  be  performed  at  the  MCS  itself  due  to  the  criticality  of  the  GPS 
mission  and  lack  of  operational  redundancy.  This  research  provides  and  validates  a  discret  event  simulation 
model  of  the  MCS  operations  center  task  fiow,  focusing  on  the  creation  and  testing  of  a  sliding-widow  MCS 
activity  scheduler.  The  simulation  was  validated  using  MCS  historical  data.  Experiments  were  conducted 
by  varying  the  number  of  ground  stations  and  satellite  constellation  rise  available  to  the  simulation.  The  re¬ 
sults,  while  not  quantitatively  trustworthy,  were  used  to  draw  general  conclusions  about  the  GPS  operational 
environment. 
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